What I've done is express the practical realities as I see them that exist within the scope of what we're discussing here - an Open Source Linux distribution and the ways that it's built.
As such, I've limited the descriptions to within that scope. As it happens, I work for a security company with multi billion $ companies and their security teams and so do have a pretty good exposure to what's going on where there's lots of money to spend on solutions and building teams. Within the industry security is about limiting risk, not eliminating it. The goal would be to elmiminate it but it cannot happen due to the practical realities of people, and that the ecosystem is evolving (software is being developed, changes to infrastructure for all sorts of reasons). Trade-offs are made in numerous places - which used to surprise me when I was younger, naieve and a bit of a BOFH! ;-)
That said, there are plenty of BOFHs in the security world and they tend to alienate themselves from the rest of the business in which they run; and often end up being fired shortly down the line because they're unapprochable, and create too much friction. The ones that survive are those that take a more pragmatic view and do what they can to minimise risk, which may involve setting up various different environments with different risk profiles (think classic DMZ-style concepts, but labeled 'prod', non-prod, pre-prod, dev, etc.).

But back to the practical reality of an OSS Linux distro:
How does a browser or a download tool such as wget/curl choose to accept the TLS cert of a web site? It uses either its own CA-cert store or uses the CA-cert store provided by the OS (in Slackware the 'ca-certificates' package).
Who provides the CA-cert store certs? why should you trust them? The Mozilla foundation details their process. It's an informative read, but I still don't know the people involved so I'll have to take their word for it all.
However, what happens when you take the word of a Certificate Authority who short-cut the processes of validation? Was it Symantec that was called out by Google for poor practice, and their certs effectively blocked by Chrome? I don't recall all of the details off the top of my head, but I think the Chrome developers spotted a pattern that shouldn't happen if certs are validated properly (or they found a cert that was issued by Synmantec that should not have passed the validation). Until that point, everyone assumed that the TLS certs provided by Symantec would guarantee that the web site was legitimate and that there was a legitimate company behind it, who would handle your credit card details properly.

Who packages the ca-cert store and provides it for your OS? This part *alone* is a key stone of the trust chain.

There are all sorts of tools to help with security, such as code analyzers and so on; but these are upstream from Slackware.
Slackware is a downstream consumer and as such we rely on GPG signatures, TLS (and the trust chain that goes with it). We rely on the projects that are included within the distribution to have appropriate measures in place to protect the integrity of their source, and to trust that the developers of it have some robust process to handle submission reviews and such.

This conversation could go on forever debating the ins-and-outs, but as I said before, at the end of it all you have to trust some basis.
Resolver's comment on how rust should be rebuilt using the original language it was written in-- ok, but what does this mean? Where's the compiler for that one?
Why should you trust that compiler? Do you even trust the language it was written in before? (I hadn't even heard of it, let alone would understand the code if I read it - so how could I even validate the code).
This is why I said it's rhetoric - once I think it through to the very end, you still end up with some result that you have to accept or not.

Another example is the mirror servers here. Let's say that there was no GPG signatures for the packages: if I knew that alienBOB pushed his packages to the Slackware UK FTP mirror directly, I'd still trust those packages because I've known tadgy (who runs that service) for years and I worked with him professionally. He has his act together with security and host management, so I'd trust him to have done all he could to make that site secure (which is also why I use it as the master server for Slackware ARM). That doesn't mean there isn't some wide open door that blackhat hackers have found and are readily exploiting; but that's just part of being in the game. In terms of payload validation, I can still validate the data I download using the GPG system (assuming the data is signed). But again, at some point I have to trust the system from which I downloaded the GPG key in the first place *and* I have to trust that the GPG binary I'm using to do so isn't compromised in such a way that it bypasses checks for this particular GPG key.

For the Slackware ARM tree, I pull all of x86 upstream repo (source, scripts etc.) over SSH from the private Slackware server that Patrick pushes to directly because that's as close to the source as I can practically get, and the server's run by Patrick.

So you're absolutely right - I limit what I will typically describe here because I know enough of the ins-and-outs to know that in the end, there's a decision to make when you need to get stuff done.
If you don't need to get stuff done, you can think it through and debate all day long.
With this in mind, and within consideration of the actual scope of what we're really dealing with here, if I'm missing anything that *practically* makes a difference, I'm keen to learn; but discussing practices that are far outside of this scope and expecting to have them exist and be relevant at the level of a downstream Linux OSS project isn't in my opinion, relevant.

6 members found this post helpful.

I know I'm right, thanks for the confirmation. You're a (good) technical professional and again, I'm not expecting you to have the capacity and understanding (depth) for non-technical subjects, simply because you lack a years-long & in-depth professional training on Human/Social Sciences to start with and it's not your professional field / interest.
In my rather long reaction (actually very short, considering how vast and complex the Human/Social Sciences are), I tried to position you in the necessary environment, providing terms and notions (definitions), suggesting that it's not the science to blame but the lack of it / the ignorance.
And finally to suggest to not go easy about security, but stay focused/vigilant and serious about it. You have a responsibility towards the community and that implies showing commitment/seriousness and not "minimalism".
I'll end in a short "British" note:
Breathe, breathe in the air
Don't be afraid to care
Leave but don't leave me (Slackware community )
Look around and choose your own ground

For long you live and high you fly
And smiles you'll give and tears you'll cry
And all you touch and all you see
Is all your life will ever be

(Floyd)

As for me, I'll keep my "wondering" and "constructive/corrective" state:
https://pics.me.me/true-terror-is-to...r-38452454.png

'nuff said

This is frankly quite insulting. Does not belong in this forum.

7 members found this post helpful.

Here is the thing; almost any attacker is going to take the path of least resistance. If someone was going to backdoor rust what is easier.


A)
Somehow introduce a compiler into the tool chain that has logic in it to recognize that its compiling the language or core libraries themselves and inserts a backdoor into that which is subtle enough to go unnoticed in the resulting binaries yet reliable enough to not cause odd behavior or breaking leading to its protection. Consider too that the backdoor its inserting depends on any particulars of the binary layout and common structures that could change it might not survive across language revisions or would be discovered at that time.

B) Get commit access through social engineering heck maybe even just join the project team and insert your back door as obfuscated source. Remember this is a complier suite here - complex beast lexers, AST generation parsing, and so fourth - not simple code to read unless you are expert. - So you basically know a truly effective security audit is unlikely.

Consider comparatively simple things like say ProFTP were actually backdoored nearer along the lines of B. Even much simpler examples of malicious code has been found in I believe all of the following repos pip, gem, npm, nuget at some point. My point is the notion of a malicous compiler secretly bugging every binary it produces (or a selective subset of them somehow) is a bit of a sci-fi-security wank. While it might indeed be more difficult to detect you initially have to overcome almost all the same controls one would to get malicious code into a popular repo and design something that is probably a lot more complex and brittle or would just go the later router knowing full well the control we have to prevent that have fallen down multiple times in the past.

As others have pointed out in this thread at some point you simply have to trust various parts of the system. You could never audit enough of it or even audit enough of the auditors to faith in the audit results to be 100% sure.. As long we are talking about general computers that is just the way it is. Now if you writing the software the micro-controler that runs locks on your bank vault sure go thru every instruction if you want it might even be worth it; but you trust the silicon?

1 members found this post helpful.

If any of it were true, I may be insulted. I am laughing because the idea that this individual feels compelled to act in such a way, and appears to have some idea of what knowledge and experience I have, what books are on my bookshelf and so on is hilarious. I would love the ability to do that, although I won't be looking in that individual's direction because I can see that it's faulty.

If anybody else has any ideas about how to become intimately familiar with the experiences of another, to know their work history, their thoughts, their conclusions and so on, please speak to me first and I'll handle all the patents and all that jazz. Bring on the $$ !
P.S. you cannot write the story arch of The Matrix - that one's total fantasy! :-)

2 members found this post helpful.

I'm sorry that you understood it that way, it wasn't supposed to. Still happy that you are not sure about your opinion, using the word "quite".
I stated that a technically trained person doesn't have to be competent in social/human sciences. This is how education in our society works these days, it has specializations. If you feel that is not OK, you have the right to change it, at least in the democratic republic of the lower lands. Start a petition, look for followers and proceed in the parliament for legal changes.

Additionally, it's in the Anglo-Saxon society where a social/human study is certified with a bachelor of ARTS and not science. It goes beyond just simple science and I'll leave you to investigate why. I'm also available to help you privately.

The subject I reacted to in this forum expressed lack of knowledge about a domain, not comprehending the relation security <-> trust and the role of security management in risk management. I felt he was eroding the trust of the distro by showing these misunderstandings, given the position he holds and expressed my concerns and explanations. Nothing more.

I believe I have the right to intellectually challenge and correct the people I trust, express my care, concerns and finally opinions.

"Human science" needs an overhaul if it cannot work with drmozes excellent reply.

This chain of trust is real, and it can be scientifically proven to work as drmoze explained.
You can do infinite amounts of repeated trials and you will find out that, unless you do EVERYTHING yourself, you must put trust into the ones who prepare a product upstream the chain (upchain?)

Slackware is not LFS, yet it still also has all the sources visible.
So, you can theoretically build it from scratch, too, with some elbow grease on your end.

But why do that if you can simply build a web of trust?
If you're that deep into 'human science' then you should know, by observation, that people trust other people more readily on things that go into their bodily systems to become a part of them (aka food and water) more blindly than you are trying to bust the Slackware teams balls with for software.

Of course it's not unreasonable to want security, but if you just buy something prepackaged in some store, something that you did not raise, under your own supervision, fed with things you analyzed completely, etc, then maybe switch down some gears here.

There's a potential backdoor in everything you don't explicitly scrutinize yourself, AND EVEN THEN...the backdoor might be inscrutable to you after all.

I mean, there was a freaking way to 'glean cryptographic keys' via the subtle audio of the circuitry a computer makes depending on which numbers were going through the registers, or something like that.


Like, they put up a freakin' microphone and the frequency of the computer hardware offered suggestions on how to crack some encryption.

Not to mention if someone really wanted your stuff, they could just hook you in the shins with a lead pipe until you talked.

Now, I realize that citing such a subtle way of getting somewhere might strengthen your point of "well then be extra thorough" (and Slackware updated its packages accordingly when a fix for that frequency thing came out) but again, without the tradeoff of trust, everyone would be constantly held up going through the entire chains of produce.

Ain't nobody got time fo dat.
It's not perfect, but things rarely are.

Again, do you go this hardball on your food? Maybe you do, but...if you apply "social sciences", I'm sure you will find a trend, at the very least, that most people don't.
Layman opinion of course, so, please, do those experiments, and publish the results so we can see what YOU are talking about, too.

Etc, would you want to do that?

Jump through all these hoops just to be a pain? Probably not.

Had a chuckle tho, cause man...whew.

Edit:
One more thing, turning the whole story around.

Yeah, you are more vulnerable if you're a 'trusting sheeple downstream consumer', but, if upstream also fixes bugs, then everyone downstream benefits from that too.

1 members found this post helpful.

There's always a applicable xkcd...

https://xkcd.com/538/

Oh please.... Send ABGA some butterflies so that he can have a truly trustworthy system and stop the nonsense discussion.

Rather condescending But as someone with quite a bit of experience in the social sciences and humanities myself, your posts in this thread don't strike me as particularly scholarly or scientific. For what it's worth, I usually like your posts on security (I'm interested in it generally myself), but you're less than convincing here, with unfocused stuff about management/business organizations and vague claims to special insider knowledge of the human sciences. I mean if you have something concrete and practical to bring to the table, sure, but I agree with drmozes here, this is mostly just rhetoric so far.

Re Slackware, if you want a maximally secure OS, then Slackware pretty obviously isn't it. But, Slackware is "good enough" for many people's needs, and in my opinion not a bad choice at all if you know what you're doing. If security is your number one goal, things like Qubes, Subgraph, Alpine, etc would be more attractive.

@chemfire (& @bassmadrigal)

I don't believe anyone is able to audit huge software projects, but with the modern source code management systems and their hierarchical structure (at least on subdomain level) you get the developers themselves (the specialists) verifying and validating the code.

That xkcd comic is a classic in both efficiency and effectiveness on the attacker side. But also an exemplary failure of the Security Management to satisfy the Risk Management on the victim side, where the security measures were limited to only "minimizing" the risks and not to mitigate them.
Speaking of cryptography, there are security solutions that actually work (resolve the risks) for such a particular case:
https://en.wikipedia.org/wiki/Deniable_encryption
- together with the common current method to escape abusive legal practices, encrypt data and send the key to a third person for safekeeping until passing the border/airport control (the security risk).

On collaboratve security, there's also:
https://en.wikipedia.org/wiki/Secret_sharing
- wondering why isn't it widely implemented for authentication and validation (committing) in public collaborative systems. The following wouldn't have happened:
https://wiki.gentoo.org/wiki/Project...8-06-28_Github
2FA won't help too much in avoiding it happening again, but the all holly "frequent backups" will at least allow the project to recover fast.
Point is, concrete technical solutions are available, but not always considered. And again, it's not the science to blame.
Finally, example where science got at its limits and "art" was required. Thankful that such "art" exists...
https://www.wired.com/2015/01/silk-r...ross-ulbricht/

@drgibbon
Your quote was already addressed in my reply to AlienBob.
I'm sorry to have left such a low impression on you, hope you'll still enjoy my future posts, regardless the subject (and my English articulation limitations). Should you get the chance to revisit the unsatisfactory posts you've mentioned, I count on your perceptiveness and hope you'll understand my focus and limitations imposed by both subject and posting format (I must admit, my reply to the subject got way bigger than originally intended). And a suggestion - you could google the "unfocused stuff" and "vague claims" keywords if you're curious and keen to learn more. It'll be off-topic here to elaborate on them.

@resolver
This is my last input here, can't help more than to confirm that you're right about your concerns, but there are no tools/means currently implemented (although potentially available) to help an end user tracing and verifying the security of the binary back to its source. I summarized my view and understanding on the SW environment at the end of my post #30 and I believe it's the upstream toolchain (compilers) devs you need to focus on in your endeavor.

No sweat, maybe it's a lost in translation thing, I didn't realize you weren't writing in your native language. Anyway, I think security can almost always be improved and practices should evolve over time, but it's got to be realistic too (e.g, even Debian doesn't have full reproducible builds yet, and that's a way bigger project).

To me, what I see here is a demonstration of your own patterns, which I observe as follows.

1. A burning need to be 'right', as evinced by your reply expressing thanks directly for it.
2. This need maybe what causes you to derail an entire technical conversation into a domain (social sciences, etc.) that has no direct bearing on the _practical realities_ of both *using* an OS, nor building one.
3. You launch into an unfounded personal attack on someone who actually does know about this stuff, when that person (me, in this instance) hasn't attacked you personally. Instead of replying to the points I make about how things _actually_ work in this domain, you change course entirely and bring in a domain and assert I have no understanding of it, in what seems to be an attempt to undermine my contributions. You expect people to then believe _your_ assessment of my skills, knowledge and history of study with no basis of proof whatsoever. You literally made it up!
Furthermore, as it happens I have been studying psychiatry for almost 15 years now in my spare time because I enjoy the complexities of human behavior, and studied psychology in my student years too.
But you didn't know that did you, only you thought I knew nothing about the domain!

This is a path we have been down before. In the past you argued with me and provided demonstrably provable dangerous advice to users of Slackware ARM.

I'm not sure what the rating on LQ really stands for, and what's funny here is that we're back at trust again.
*I* don't trust what you say on this forum, as it's clear that you invent information to suit your needs, and continue to try to prop it up, then find exit routes which involve attacking your interlocutor when facts are presented that you cannot respond to directly.

If anybody is interested in how security features in building an OS at this level of OSS projects (we're not talking about a Red Hat here!), what I have written is a pretty good summary of how it works.

4 members found this post helpful.

I was going to leave this one, but in between hacking on rust for a bug report the OP raised in the ARM forum, I had some more thoughts.

abga: I don't know why you are on this forum, although to me it seems that you need to satisfy your need to be 'right', and so you do so through your contributions.

I contribute to this forum because I've spent a considerable amount of my life working on this project, and I also like helping people and exercising that knowledge in a consultative way (which is also why I do this professionally).

If I see something that I know to be incorrect or could be embellished, I'll pop in to a thread from time to time: not to be right and correct someone, but to offer the insights that I have from actually building from scratch and maintaining the entire ARM port for getting on 20 years. I don't contribute to that many threads for that reason: I have nothing different to contribute, or I have no experience in the area being discussed.

Why you feel the need to debate the descriptions of my own experiences of how this is done (which incidentally is how it's done by all of the Slackware dev team - what is it? downloading sources, verifying the authenticity, enabling secure access to source repos etc -- these are things any user of Linux can do and understand what I have said to be true), I cannot ascertain.

You say that you think my position in the community is a problem because I'm wrong and so people might believe something that's incomplete or wrong/whatever, and don't have the intellect to consider a big picture; yet as you do this there's the inconvenient issue that - and this is one example - you persisted in telling users of the distribution I maintain, that instead of following my advice of upgrading the packages (which caused the OP to have their self-compiled packages break), instead they should prop it all up with symlinks.

When explained to you the reason for API breakage, you persisted in espousing dangerous advice. This is an example of trust: there is plenty of documentation available on the web that explains about versioning with APIs and ABIs, and why your suggestions were unhelpful long term.

At that point I stopped reading what you wrote, because it was clear to me that if you persisted in your opinions, which may endanger the users of the system I put out, which may cause me to spend more of my personal time trying to chase demons created by the application of your flawed advice.
I simply ignored you as one of those trolls you have to put up with.

Until now. You even bring what you _assume_ is my nationality into it! It's clear that you don't know what my nationality is, and I don't furnish anybody with it it either, apart from the passport office! I don't know what ideas are in your head.
Again, I don't know what your purpose of being here is. You attack the developers of the OS you apparently love. You refuse to listen to the experiences of one of them who just happens to enjoying sharing how he works, and tell him he's wrong - yet it's *actually* what's being done, and his explanations are technically sound and verifiable by anybody.

The trust system on LQ is meant to give some indication as to whether you could follow this person's advice, particularly if it requires doing some system-level config that you're not familiar with.

In my eyes, if someone demonstrates utter persistent confidence in a subject, and won't even discuss the actual points raised (instead, veers off into another domain and uses some supposed knowledge (sorry but *I* don't know what your work history, academic studies are -- yet you purport to be intimately aware of mine)), it undermines *anything* else that they say to me. If they are so confident in one thing, and you know it's wrong, would you really trust something else they say in a domain in which you are *unfamiliar*? I don't. You may indeed have lots of information that is correct, yet I am unable to validate it for myself; but because I know you are confident yet it's certainly not matching my own experiences, I'll never trust you.

Be aware that I could have written this message incredibly differently, but given my position (of which you are aware and apparently seems to be some issue for you), I choose not to eviscerate you publicly. The reason the people on this forum are Slackware developers/contributors is because we *contribute* things that are useful and work, and have done so for many years. It's as simple as that. We're not geniuses, we're not superstars or heros or are people who get everything right. Hence why I ask the question: why does anyone here trust *anything* that is put out under the name of Slackware, or quite frankly anybody else in this community?
You take a leap of faith. It's that straight forward, yet you bring in unrelated matters. You don't need to accept this fundamental truth, but it's there clear as day, regardless.
I don't know why you chose to attack me in such a way, but this isn't what *I* want to see in this community.

Given what you have demonstrated publicly here, I'll leave it with the moderators to jump in if they want to review your reputation as a 'Senior Member' and your reputation score. If this were still on the old Slackware ARM mailing list, we wouldn't be at this point: I would have blocked your email address already, because my standards won't allow this. I do not have that privilege in this environment.

As regards the OP's question: this originated in the Slackware ARM forum. As it happens, the OP has found some weird bug in the ARM rust architecture quadlet toolchain name, when Firefox is building with clang. Unfortunately the OP (as far as I can tell) mistook some build messages from rust, suggesting to automatically download a binary toolchain of the *expected* name, and mistook that as Slackware using untrusted binaries to build itself.
As it happens, ultimately Slackware - as does all the other distros out of necessity - used the binaries to bootstrap our own rust build.
All this discussion ultimately boils down to having to trust something or someone to build your own platform.
It's the same with gcc-gnat - you needed a gnat compiler to compile gnat. alienBOB already discussed how you could go to the previous stage prior a rust compiler, and look at the original language; but then you find 'But how did OCAML (or whatever it's called) get compiled?'
If OCAML was written in C, ok great news... no binary compiler required.
but wait.. my Compiler? at one point there was no C compiler to *compile* C code.. so back up to eventually machine code.
Do I trust that chip manufacturer not to modify the instructions I send it?... let's look at Intel - didn't they have some backdoors into the management unit?

Sorry for the long post everyone - I hope the bit immediately above was useful in some way. That's what the original poster's concern actually was.

4 members found this post helpful.

Bravo! So far, posters here have nailed his comments down: insulting, condescending... I'll add presumptuous (but you capture that in your posts), arrogant...

... giving dangerously misleading advice.

It's overly generous to attribute this to a lack of command of the English language (another poster was allowing him the benefit of the doubt.) Both the essential overt message and the subtext come through loud and clear.

Sorry I can't contribute to the *original* point of this thread. I don't have the expertise.

But I'm reading the thread to learn about the topic, and I hope to gain enough knowledge and skill that I can help someone out some day.

abga, please, if someone disagrees with you on a point related to the original post, keep to the topic - don't derail it with redirection and misdirection into irrelevance.

TKS

2 members found this post helpful.