[-] FizzyOrange@programming.dev 1 points 2 weeks ago

I think there are some crates that wrap the unsafe code for you, e.g. https://github.com/rodrimati1992/abi_stable_crates/ (I haven't ever tried it).

[-] FizzyOrange@programming.dev 1 points 2 months ago

Ah fair enough.

[-] FizzyOrange@programming.dev 1 points 2 months ago

That is another tool you can use to reduce the risk of malicious code, but it isn't perfect, so using sandboxing doesn't mean you can forget about all other security tools.

There is no way to automatically analyze code for malice, or bugs with 100% reliability.

He wasn't asking for 100% reliability. 100% and 0% are not the only possibilities.

[-] FizzyOrange@programming.dev 1 points 3 months ago

Ah yeah I misread your comment. 100% agree.

[-] FizzyOrange@programming.dev 1 points 3 months ago

I don’t want to sound condescending, but what do you think all this talk about Rust and AI tools is about?

Yeah I am aware. It's very good that they're looking at it and great that Linus is supportive and not a stuck-in-the-mud. Doesn't invalidate my comment thought. He's still saying security bugs are no worse than other bugs.

And if some feature turns out to be a gaping security hole you’ll quickly see it turn into a bug. That’s what the quote is about. Every security issue is a bug so it has to be handled like a bug and squashed.

I mean... I don't think that's what he's saying. Nobody is saying not to fix security bugs...

[-] FizzyOrange@programming.dev 1 points 3 months ago

Should what be handled? Security vulnerabilities? Here's how you should handle security bugs differently to other bugs:

  1. Report them separately and clearly. Don't hide by omission the fact that they are security bugs (common practice in Linux apparently). Coordinate with major vendors how to push fixes.

  2. They are generally more important than other bugs so you should put more effort into detecting and preventing them. E.g. using fuzzing, sandboxing, formal methods, safer languages, safety annotations, etc.

  3. They have high value on the grey market and people actively try to create them, so you need to design your system under that assumption. An obvious thing to do is software isolation so a bug in - to pick a random example xz - can't bring down ssh. Software isolation, microkernels, sandboxing etc. help with this.

There's no way you can say "they're just bugs". Maybe in the 80s. It's not the 80s.

[-] FizzyOrange@programming.dev 1 points 3 months ago

On the web I would stick entirely with Typescript. There are plenty of server side Typescript systems; you don't need to resort to Python.

Most recently I've been using Deno's Fresh framework which is fantastic. Very easy to use and suitable for beginners IMO since you can start with traditional request per page & static templated responses - no complex state management.

[-] FizzyOrange@programming.dev 1 points 5 months ago

Yeah but be prepared for a lot of pain if you want to distribute your app. Python tooling/infra is abysmal.

[-] FizzyOrange@programming.dev 1 points 6 months ago

Yeah definitely! I wouldn't hold your breath though. Especially as that's pretty much an escape route from POSIX. I doubt they'd be too keen to lose power.

[-] FizzyOrange@programming.dev 1 points 6 months ago

Are you suggesting that you prefer to do the type validation upon execution?

No. But I would like them to actually be done! If you just write some Python code and put type hints in it and don't do anything else then those types are not checked at all. It requires some set up and a third party tool to use them properly.

It is a bit more complicated than that. Here’s a quote

That quote is exactly what I was saying. It does not require any particular processing or type hints.

Type checkers can and do differ in whether they accept a particular piece of code.

[-] FizzyOrange@programming.dev 1 points 6 months ago

Salty huh

Very. Python's shit tooling has cost me literal weeks of my life. It's so bad. Have you ever used Go or Rust? If not go and try them and then you will realise that it doesn't have to be like that.

Saying you need to set up type hinting in Python shows that you’re the one assuming it’s a hassle like TS

I'm not assuming. I have done this. It is absolutely a hassle. TS isn't exactly hassle free but it's still better than Python.

where you need a different runtime to have access to something the language (JS) should have provided from the start.

You mean like MyPy or Pyright? At least Typescript defines the semantics of its type hints. Python only defines the syntax! You can have multiple type checkers that conflict with each other!

Everything you need is provided by typing, which is included in a Python install. Just import it and start using it.

If you do that, nothing will actually be checked. You need to explicitly run pyright in CI.

[-] FizzyOrange@programming.dev 1 points 7 months ago

That's totally orthogonal to whether your config is source code or not though.

view more: ‹ prev next ›

FizzyOrange

joined 1 year ago