We need a better way to sign and verify software. Clearly companies like Microsoft and Apple have not been good for the open source communities and are inhibiting innovation.
GrapheneOS is doing lot of things right in this regard. Robust permission system adopted from AOSP and hardening by default in every imaginable way. Things like hardened malloc, storage scopes are excellent security features. Malware cannot do much even with the default settings.
With a file system driver like Veracrypt, if it’s malicious, the OS might keep your computer safe, but not your files that you store in that file system.
Actually, Windows by default will not trust code signed by CAs that issue certificates to websites. It will only trust code signed by CAs that are approved for code-signing, which isn't a very large set anymore. Moreover, recent CA/Browser Forum policies forbid dual-use CAs anyway. If Let's Encrypt issues you a certificate for a web site, it cannot be used for code signing.
It's possible that they could start issuing separate certificates upon specific request for code signing purposes, but it's doubtful they would be willing to meet Microsoft's requirements for such certificates, so their code-signing CA would not be added to Windows's trust store, rendering the certificates it issues useless.
The ACME protocol, the key automation technology that makes Let's Encrypt possible, performs domain validation only. It verifies that you, the person (or bot) making the request, are an authorized administrator of the DNS records, or port-80 HTTP server, for that domain. This is directly relevant to, and generally considered sufficient for, HTTPS.
However, domain validation is almost completely irrelevant to, and insufficient for, code signing. Microsoft's rules (and Apple's, incidentally) require establishing the identity of a legal person (individual, or preferably, company). There is no way the ACME protocol can do this, which means that the process is totally out of Let's Encrypt's wheelhouse.
> However, domain validation is almost completely irrelevant to, and insufficient for, code signing.
It's actually the only thing that provides any kind of assurance to users. It's not like end users know if FuzzCo is the correct developer for FooApp but they know fooapp.com.
A web site is identified by its URL, which contains its domain. Any good HTTPS implementation cross-checks the requested domain against the SANs of the cert, and does so automatically.
There is nothing in a piece of random software obtained from some random source that authoritatively connects it with a particular domain. Without bringing an App Store or other walled garden into the picture, the operating system must evaluate an executable file according to the contents of the file itself. On cold launch, the information in the certificate can be presented to the user, and the certificate issuer can be checked against the O/S trust store, but nothing equivalent to the HTTPS domain check can be done.
DV certs work for the web because of that intrinsic connection between web site and domain. They fail for arbitrary software because of the lack of such a connection. The trustworthiness of code-signing certs comes from the relatively difficult process necessary to obtain them, and not the name attached to them. The identifiable legal entity to which the certificate was issued is more useful to the O/S vendor, as a harder-to-evade ban target, than it is to the end user.
What would be the point? How would you prevent malware from being signed? Currently, code signatures are used as a signal for trustworthiness of the code.
Only signal is that whoever is in the subject DN (highly) probably signed the code. There's 0 signal about trustworthiness of the code in the signature. Thrustworthiness signal is in the behavior/reputation of the signer.
Pretty sure there were historically a lot of apps that stole peoples contact lists and were signed properly. Certainly in the Android world.
On the source code side, I quite like the way Guix does things, i.e. needing every commit to be gpg-signed. They even have a handy tool for verifying the repo[0] but I'm not sure how viable this is for non-OSS projects.
I completely agree that requests are what should be charged for. But I think there are two things, given that requests aren't all going to cost the same amount:
1. Estimate free invoicing the requests and letting users figure it out after the fact.
2. Somehow estimating cost and telling users how much a request will cost.
im fiarly certain the knob on the machine that controls length of redundant comments and docblocks is cranked to 11. it makes me curious how much of their bottom line is driven by redundant comment output.
I think it's funny and interesting how LLMs are commoditizing information generation. It's completely expected, but also somewhat challenging to figure out what the best combination of "learning" "fact" systems is.
I'd be curious to know more about how this compares to other approaches.
My #1 issue with Neovim is the new ! Behavior. Anyone know how to make it toggle the alt terminal screen and just output to the primary screen like it does in Vim?
I understand the annoyance, but my workflow for years has been running (n)vim in tmux. So I never need to run terminal commands from the editor, that’s what other tmux panes/windows are for.
The new ! just isn't as useful, and it's harder to get back to see the outputs. The old ! Was just a drop in way quickly do something like ctrl-z command fg.
I don't think explicit naming of impls is wise. They will regularly be TraitImpl or similar and add no real value. If you want to distinguish traits, perhaps force them to be within separate modules and use mod_a::mod_b::<Trait for Type> syntax.
> An interesting outcome of removing coherence and having trait bound parameters is that there becomes a meaningful difference between having a trait bound on an impl or on a struct:
I don't think fully-qualified paths are enough on their own. You also need some way to designate that an impl is symbolically unique and has to be referred to by path. Otherwise, you still end up with a problem where the compiler doesn't know which implementation to use unless you precisely name it.
You depend on crates A and B. A impls Foo for Bar. You pass an instance of Bar to a function that accepts `impl Foo`. You are happy. Later crate B adds an impl of Foo for Bar. Clearly _at least_ one of these must be an orphan impl, but both could be. Suddenly it's ambiguous which implementation of Foo you're talking about, so you break because B added an impl.
There are many potential problems of this flavor with letting any `impl Trait for Type` be an orphan impl and then referenced by path. What happens, for example, if an impl that was an orphan impl in one version of A becomes a coherent impl in a later version of A?
I think there has to be special syntax for named/path-referenced/symbolic impls, even if the impl does not have an identifier name, so that the compiler can know "this impl only resolves if you tell me _specifically this impl_" and the impl provider has a way to create a solid consumer contract about how to use that impl in particular.
Also, not having an identifier name would mean you can't have different impls of Foo for Bar in the same module. That's probably not a limitation anyone would care about, but it's there.
Using the mod name would give it a unique name, just implicitly through the module, so I don't see the issue, unless you wanted to allow a single module to allow multiple impls of the same item.
I also don't see an issue with having multiple impls of the same trait, as long as they don't provide duplicate items inside a module. I often do multiple impl blocks to break up larger logic and organize docs, though this is generally not for trait impls, but I don't see why it couldn't be.
Let me be clear though, I'm not saying this is the best path forward on the coherence/orphan situation necessarily, just a minor critique of the blog posts position. This is a famously tricky issue, and I suspect there is no silver bullet here. Though I have always wanted some way to add flexibility to the orphan rule.
> You depend on crates A and B. A impls Foo for Bar. You pass an instance of Bar to a function that accepts `impl Foo`. You are happy. Later crate B adds an impl of Foo for Bar. Clearly _at least_ one of these must be an orphan impl, but both could be. Suddenly it's ambiguous which implementation of Foo you're talking about, so you break because B added an impl.
I think that's fine. Same as what happens if B adds a new function with the same name as a function in A that you were using unqualified.
> What happens, for example, if an impl that was an orphan impl in one version of A becomes a coherent impl in a later version of A?
reply