Rethinking Fedora's compiler policy [LWN.net]

Rethinking Fedora's compiler policy

Posted May 6, 2021 4:28 UTC (Thu) by SomeOtherGuy (guest, #151918)
Parent article: Rethinking Fedora's compiler policy

Wasn't there a problem recently with a Python cryptography package not being build-able by GCC (because Rust?) so some weird architectures are isolated as LLVM doesn't support them?

I know Fedora is not Debian but do they care?

to post comments

Rethinking Fedora's compiler policy

Posted May 6, 2021 4:29 UTC (Thu) by SomeOtherGuy (guest, #151918) [Link] (13 responses)

Woo my comment didn't get eaten this time. Don't you love it when you put effort and research into a response only for it to never ever show up. Awesome.

Rethinking Fedora's compiler policy

Posted May 6, 2021 4:44 UTC (Thu) by njs (subscriber, #40338) [Link] (12 responses)

Fedora already allows LLVM to be used for packages that *can't* be built with GCC. Currently that includes all Rust packages.

Rethinking Fedora's compiler policy

Posted May 6, 2021 22:50 UTC (Thu) by SomeOtherGuy (guest, #151918) [Link] (11 responses)

Encouraging both if not upstream would obviously improvement (eg upstream uses X, allowing X and at the maintainers' discretion, Y to be used) could only improve matters.

I don't see how a maintainer exclusively using Y would be different if upstream uses X - provided they cooperate?

I would however not like to see this arch split get worse

Rethinking Fedora's compiler policy

Posted May 7, 2021 0:22 UTC (Fri) by pabs (subscriber, #43278) [Link] (10 responses)

There are efforts towards combining Rust & GCC:

https://github.com/Rust-GCC/gccrs
https://github.com/antoyo/rustc_codegen_gcc
https://github.com/sapir/gcc-rust/

Rethinking Fedora's compiler policy

Posted May 7, 2021 21:50 UTC (Fri) by SomeOtherGuy (guest, #151918) [Link] (9 responses)

Woo github links, I'm sure they're worth depending on

Really?

Posted May 7, 2021 21:56 UTC (Fri) by corbet (editor, #1) [Link] (6 responses)

What, exactly, would be the point of a comment like this?

It's not hard to understand the concerns around proprietary hosting operations like GitHub; I suspect the person you are replying to understands them rather better than you (or I) do. But there is a lot of useful code hosted on GitHub. What is the value in heckling somebody trying to point to some of this code? Please don't do that here.

Really?

Posted May 8, 2021 1:31 UTC (Sat) by SomeOtherGuy (guest, #151918) [Link]

Pabs replied below and pretty much covers it, but there's also the fact that by project number only 99.9% of github is crap

Sure there probably is some stable and reliable software I use every day on there and it may even be the primary mirror, but we should not go "ooh a github link - legitimacy" - as the other guy covers

Really?

Posted May 8, 2021 1:38 UTC (Sat) by SomeOtherGuy (guest, #151918) [Link]

I also offer you this corollary:

(Assuming the projects are relevant and could help Python:)

IF they were dependable and great projects THEN the Python lot would surely use them and give that crypto library to the masses

The contrapositive (logically equiv)

IF the Python lot are not using those THEN they are not dependable and great projects

A little inaccuracy saves a lot of explanation, but you get the idea

Really?

Posted May 8, 2021 1:59 UTC (Sat) by SomeOtherGuy (guest, #151918) [Link] (2 responses)

At the risk of earning the ire of #1 there, I proffer one more thing

Ancient paper by Denis Ritchie I believe (one of them) an essay on trusting trust, in it he builds a toolchain which is able to hide a back door (or some such) into the compiler, that passes itself on to new compilers and is invisible (as they are also adjusted) by nm, and whatever the old version of objdump and friends are

If we were allowing Rust into our computers I would expect no less caution from the Python developers especially on cryptography.

I hope this makes my case of why my sarcastic "oh a github link" comment was justified - we should not use that as a credential

Reference to "Trusting Trust" (WAS: Really?)

Posted May 9, 2021 1:56 UTC (Sun) by josephrjustice (guest, #26250) [Link] (1 responses)

Ken Thompson.

"Reflections on Trusting Trust", his lecture when he was presented with the Turing Award.

Here's a link to an electronic version of the written copy of the lecture: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_... . If one doubts that the electronic copy is an accurate reproduction, I expect that printed copies of the original academic journal it was published in can be found at most reputable academic libraries (at least in English-speaking countries).

This link was the first hit when I just now did a Google search on the phrase "trusting trust" (not including the quotes).

You're welcome.

Reference to "Trusting Trust" (WAS: Really?)

Posted May 10, 2021 22:29 UTC (Mon) by SomeOtherGuy (guest, #151918) [Link]

That was it - TBH I figured we'd all heard about it - so yeah pulling compiler stuff from github seems less wise than "try this wordpress plugin"

Honestly the thing that surprised me was how easy it was for the thing to pass itself off in future compilers, that spooked me a bit, I figured "sure yeah do that" - but to have it insert itself into compilers it builds (with decent accuracy, I imagine it can be defeated) is still REALLY impressive

I'd never question objdump -D

Really?

Posted May 8, 2021 3:07 UTC (Sat) by SomeOtherGuy (guest, #151918) [Link]

Sorry for the quad post, a comment that seems to be empty (808) has showed up with "P" status, I replied to it trying to figure out what it was (asking for help and mentioning I checked the FAQ/RTFM) and I cannot see those on the article, but they have "A" status?

https://lwn.net/Articles/855810/

Like this

I just want to make sure I've not done anything wrong (with the system) but the stuff of substance appears. So nothing is lost anway

Rethinking Fedora's compiler policy

Posted May 8, 2021 0:43 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

All three projects are in the very early stages and are very unlikely to be usable at this stage. Hopefully they all mature and their changes get merged into the relevant places, the authors of gccrs for example plan to get it merged into GCC.

There are plenty of dependable projects hosted on GitHub, the hosting service doesn't contribute to a project's dependability, as long as the project keeps good backups so they can move to another service.

Of course GitHub being a service owned by a convicted monopolist and running proprietary software isn't great. We need Free Software projects to run Free Software tools on their own infrastructure, which is why my GitHub profile links to mako's "Free Software Needs Free Tools" article.

https://mako.cc/writing/hill-free_tools.html
https://github.com/pabs3

Unfortunately the large tech companies, some of them venture capital funded, have monopolised (and consequently I think shrunk) the market for sysadmins, so various projects (even Python!!) have switched away from self-hosted solutions towards proprietary services, mainly to avoid the sysadmin work necessary with self-hosting both software and hardware, since those with strong sysadmin skills joined large tech companies and others had their remaining skills atrophy after moving to proprietary services.

The network effects of GitHub and the attractiveness of outsourcing your sysadmin work needs mean it is very unlikely we will see much of a switch away from GitHub. The only thing I can see that would disrupt this cycle would be a move away from the Web and towards native apps and development environments based on locally installed software and distributed protocols. I don't expect to see these things within my lifetime though.

Rethinking Fedora's compiler policy

Posted May 8, 2021 1:44 UTC (Sat) by SomeOtherGuy (guest, #151918) [Link]

I do agree with you on the sysadmin thing, I respect them a lot more than I did when I started programming professionally (something I've always tried to be worthy of)

Not sure about the project having backups and being able to migrate, we all know we should backup, not reuse passwords ect, and I will tentatively admit that I'm failing on that front ;)

I expect many of those projects are too - unfortunately.

PHP recently took the change BTW