/g/ - Technology
install openbsd
[Make a Post]File: e31464ace62befbafd179aa72337b5a25c94a14a732d72f025d794c4ce069835.png (dl) (8.88 KiB)

>>1720
>gcc
gcc is a slow, bloated, useless piece of cancer, which makes it impossible to audit anyway if the GNUtranny maintainers decided to slip some shit in there. Use TCC or write your shit in assembly instead.
Anyway, if you want to download gcc, use https://ftp.gnu.org/gnu/gcc which is over HTTPS obviously. That's practically the best solution available even though HTTPS itself is useless cancer which can be trivially subverted by any single one of the over 200 certificate authorities in existence.
TL;DR don't even bother if you are serious about security
File: cda05b7b4ccb07dee3019af6f366707267606ee682dd2e18499811d0e5a21533.png (dl) (437.25 KiB)

>>1723
>then why is it used to build linux?
Because linux is retarded trash written by someone who thought it wasn't going to be a serious project. Pic very related.
>Doesn't e.g. openbsd rely on gcc too?
Not anymore. Several years ago they switched to clang, which is very shitty as well but nowhere near the level of retardation that is known as GCC. At least clang produces smaller binaries and follows the UNIX philosophy somewhat, being made up of modules (like LLVM, opt, clang, and clang++) rather than being one monolithic piece of crap.
Rust apparently provides no signed tarballs, neither does nim.
Why is that?
Actually, why isn't there a way to sign/verify VCS trees?
In gentoo ebuild maintainers include metadata of a hash of the file you are supposed to download for the source code.
>>1729
You can with git.
code signing is a joke in every modern OS. they completely miss the point. every piece of code you get should be signed in the same way and it should be standard procedure to verify the signatures automatically (by your software). the closest thing is what sane distros do but that's heavyweight and only a limited selection of packages. also signing should be done per function (automatically), not per package.
File: 1db89ef60bee474c4a419f7cfc36b148d034485937dd1702bfa8fa8c59f2f684.jpg (dl) (126.87 KiB)

>>1720
I build LFS about once a year, and a while back I made a point of downloading and verifying (or attempting to verify) each piece of software required to build the system to see how securely the basic components of a Linux system are distributed. I was surprised at how some of the software was distributed, either over unencrypted connections, or without any kind of checksum, or not signed, or some combination of the above.
For example, IIRC it was zlib that was distributed over http (no https option) and an MD5 or SHA1 hash was provided, which is of course useless, because if Mallory is intercepting your internet traffic and can feed you a malicious copy of the zlib tarball, they can certainly feed you a hash derived from their malicious zlib.
Much of the software was distributed from Sourceforge, which at the time distributed downloads mostly from various mirrors, and even if the Sourceforge project page was delivered over https, it was a crapshoot as to whether the mirror you were directed to would be http or https.
Another funny thing about Sourceforge: for each download in their "Files" section of a project, they show you how many downloads each file has received in the past week. Many of the tarballs had hundreds or thousands or downloads, but when a corresponding .sig or .asc file was available, it would have only a handful of downloads, or even 1 or 2. So even when a signature is available, the overwhelming majority of downloaders aren't verifying it. I wonder how many of them are packagers for distros!
The situation has improved marginally. More of the software required to build is distributed over https and is signed or hashed now. I think the zlib site is https now, for example.
Of course, none of this helps the fundamental problem that even a PGP signature is useless to most downloaders, because unless the signer's key is signed with a key you trust, you really have no idea whether it's the actual distributor's key anyway. The PGP web of trust is a neat idea, but it doesn't work well as a secure software distribution system for thousands of downloaders out in the tech hinterlands who've never met anyone else in person who uses gnupg.
Also, while getting a download over https might protect you from a skiddie on your local network feeding you a malicious download, it's still vulnerable to powerful state-level actors. But that's a flaw in the whole idea of trusting CAs.
Anyway, I don't know if "most code" isn't signed, but a lot of it isn't, and my point is that there's a lot of flaws in the way software is distributed in general. It's a giant clusterfuck.
>>1758
Great post. And even if the code were to be signed you'd have to trust the person(s) signing it.
>>1758
The problem with the Loonix distribution model is that people are allowed to distribute shit like that in the first place. With a BSD-like distribution model, you now only have to trust the maintainers of the BSD you are using, since they will ensure all your utilities and basic libraries are trustworthy.
With an OS like OpenBSD which takes security seriously, you have a better guarantee that what you're getting isn't full of CIA nigger malware, especially since if anyone found out that if they were fucking with the binaries their reputation would be completely gone and literally no-one would use their OS anymore.
>>1750
Until recently ebuilds were neither verified nor fetched through a secure channel. Idk how anyone can use a distro with such history.
>>1758
Great post.
>>1759
Of course you'd have. To run the code you have to trust the person(s) who made it. But if you're running unsigned code you are "trusting" a virtually unlimited number of people.
>>1760
Shitty post.
>The problem with the Loonix distribution model is that people are allowed to distribute shit like that in the first place.
The phenomenon isn't Linux-specific.
>With a BSD-like distribution model, you now only have to trust the maintainers of the BSD you are using, since they will ensure all your utilities and basic libraries are trustworthy.
The same could be said about any linux distro that implements package signing (that's every major distro nowadays). But that can only be said assuming you are only using software that's in the repos, no matter what OS we are talking about.
Also, there's little meaning in trusting a maintainer to fetch unsigned code over http and then sign it. Unless of course you can trust that person to manually verify all the code with every update, which is quite dumb.
>With an OS like OpenBSD which takes security seriously,
AFAIK OpenBSD only started signing packages around the time ArchLinux did.
Also they recommend updating the ports tree without verifying signatures. The connection to the server is secure (assuming you can verify the fingerprint), but that's still worse than actually verifying code signatures.
Also I wonder why secure port tree fetching isn't automated.
I may be mistaken about OpenBSD though.
File: b0f7b57d4ad5882c8460d58b52c1b6dccd19956be575fb87e3350d73e4044325.jpg (dl) (82.66 KiB)

>>1768
>OpenBSD
>shilling
No chance. They barely had enough money to operate last year.
I guess it's just a reaction to the undeniable evidence of Linux's pozzing at the hands of Corey Dale and co.
Also the fact that hapase uses openbsd (allegedly) probably draws openbsd supporters to nanochan.
[Catalog][Overboard][Update]
[Reply]16 replies
Is most code not signed? I can download e.g. linux sources tarball with a signature, but what the gcc site recommends(?) is svn checkout, is that at the very least done over https or something?