> Unfortunately you can't really statically link a GUI app.
But is there any fundamental reason why not?
> Also, if you happened to have linked that image to a.out it wouldn't work if
> you're using a kernel from this year, but that's probably not the case ;)
I assume you refer to the retirement of coff support (in favor of elf).
I would argue that given how long this obsolete format was supported was actually quite impressive.
Is there a reason the users must see all of the historic data too? Why not just have a post-commit hook render the current HEAD to static files, into something like GitHub Pages?
That can be moved elsewhere / mirrored later if needed, of course. And the underlying data is still in git, just not actively used for the API calls.
It might also be interesting to look at what Linux distros do, like Debian (salsa), Fedora (Pagure), and openSUSE (OBS). They're good for this because their historic model is free mirrors hosted by unpaid people, so they don't have the compute resources.
I'm not OP but I'll guess .... lock files with old versions of libs in. The latest version of a library may be v2 but if most users are locked to v1.267.34 you need all the old versions too.
However a lot of the "data in git repositories" projects I see don't have any such need, and then ...
> Why not just have a post-commit hook render the current HEAD to static files, into something like GitHub Pages?
... is a good plan. Usually they make a nice static website with the data that's easy for humans to read though.
Yeah, I hate how it made housing things locally without a proper domain name very difficult. My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.
There's certainly advantages to easily available certificates, but that has enabled browsers and others to push too far; to be sure, though, that's not really a fault of Let's Encrypt, just the people who assume it's somehow globally applicable.
> My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.
If you're not encrypting local network traffic then any rogue device on that network can decide to intercept it and steal your admin password. That's one of the biggest reasons why we adopted HTTPS in the first place - whether a host is public or not isn't relevant.
It doesn't need a "globally" recognized certificate signed by a public CA, self-signed ones are fine. At home I manage mine with XCA. I have a root CA that's installed on all of my devices, with name constrains set to ".internal", ensuring it can't be used to sign certificates for any other domains.
A related issue is that most consumer devices (both iPhone and current Android) make it impossible or extremely difficult to trust your own root CA for signing such certs.
Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).
You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.
It's technically possible to get any Android app to accept user CAs. Unfortunately it requires unpacking it with apktool, adding a networkconfigoverride to the XML assets and pointing the AndroidManifest.xml to use it. Then restitch the APK with apktool, use jarsigner/apksigner and finally use zipalign.
Doesn't need a custom ROM, but it's so goddamn annoying that you might as well not bother. I know how to do these things; most users won't and given the direction the big G is heading in with device freedom, it's not looking all that bright for this approach either.
A long time ago when I was playing with rolling my own PKI, each of Android, iOS, Chrome, Firefox, and even Internet Explorer allowed me to install a root CA by opening the .crt file. From what I remember, iOS popped up some warnings and added the cert as part of a profile, but it did work.
I know things like MDM/Intune/Group Policy/etc and such can A) faciliate doing this on a large number of devices and B) prevent users from doing this on their own.
I don't want to trust my own root CA as I don't trust myself to keep it secure.
I want to important it only for a specific set of domains. "Allow this rootca to authenticate mydomain.com, addmanager.com, debuggingsite.com", which means even if compromised it won't be intercepting mybank.com
You can absolutely do that with name constraints extension set on the root CA certificate. You should verify compatibility but it's pretty universally supported on modern browsers and consumer devices last I checked.
If you generate the root CA sure. However name constraints aren't well supported.
A far better option would be to allow me, the user, to do this in the user agent. I can import my mitm cert and today I can trust it for "abc123.com" and point that to something I want to access in that manner for some reason, but tomorrow simply toggle that trust off.
If I find that I want to use a specific website and want to do something with the traffic, then I could point that DNS to my middle-box and turn that on in my browser. With name constraints I'd have to regenerate the root certificate with the new domain, and then re-import it.
the entire concept of the name constraints puts the power into the CA issuing person rather than the user.
Where are you finding that name constraints aren't supported? I've only come across that on embedded/IoT devices. They work fine for me across Firefox and Chrome on Linux, on Android, and they are supposed to work fine on Apple devices too.
> If I find that I want to use a specific website and want to do something with the traffic...
I agree but that's a different problem. If you just need a certificate for your router and some internal services (the original discussion), you can do that using an internal root CA and you have nothing to worry about as long as you using name constraints.
On IoT devices without nameConstraints support I just use an alternative CA certificate without name constraints (same key, different extensions).
Yeah, I learned that using Netscape 6 with a row of blue balls for icons; going from the older Mozilla builds with the Netscape 4-style icons it was a definite downgrade. Pheonix had a row of orange balls; they later switched to IE-style icons with distinct shapes, which was better.
The recent Android releases where everything is a squircle really sucks too.
Shouldn't the files be signed by Microsoft, with a timestamp signature? That should (barring somebody locating a relevant private key) still mark them as not having been modified.
Of course, how many people would know to check for the signature (especially in the case the site went malicious and therefore wouldn't tell you to do so) would be a different question…
It’s hard to teach people it’s worth their time to double-check these things of course, but I try to show a chain of trust:
1. Files come from Wayback Machine, which is trusted to serve legitimate snapshots
2. There is a sha1 and size listed for most files (though these come from Wayback)
3. Checking signature is easy enough from Explorer
Perhaps a page on “how to know this is legit” is a good idea to help educate about this. The goal of the project is to have legitimate downloads with good SEO, without having to cut through ads/spam/sketchy redirects (still has a few ads but intentionally non-obtrusive), so people aren’t blindly downloading from sketchy sites.
There's widespread issues with power banks in China, with a new CCC certification required, and recently something about upgraded enforcement because previously certified devices having been found to have issues.
I'd rather go with a brand that does proper costly recalls over one that just lets everybody keep the dangerous products around.
I think the only place I'd seen voting that wasn't just up or down was Slashdot, and all that did was let the user adjust weights for the dimensions. I do miss their voting though.
Isn't that all you need? What you want to see depends what you're looking for! e.g. to extend my example, perhaps you've found the literal answer and now you're looking for context, or usage examples, or gotchas, or...
As far as I can understand from the documentation, that doesn't actually specify in that config that one of them is required, does it? That is, if they _all_ fail to install as far as the system is concerned there's nothing wrong? There will be runtime errors of course, but that's sort of disappointing…
It's also terribly documented. As an example, I don't think `satisfies` is in the docs outside of release notes. There's lots more stuff like that, which makes using it kind of frustrating.
Also, if you happened to have linked that image to a.out it wouldn't work if you're using a kernel from this year, but that's probably not the case ;)
reply