Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.
i found it here
http://lkcl.net/reports/wot/ it's dated 2017 (not a bad
guess, 4 years). please bear in mind, the primary reason for writing it
was to help a group that was (still is) severely lacking in both technical security understanding and also infrastructure within their distro.
as a group they genuinely believed that SSL would be beneficial in some
way. a leading gnunet developer on the list made one single comment and
then, knowing that the size of the group was large and comprised largely non-security-conscious individuals, knew that any further discussion
would be... unwise, declined to take part further.
naively, i tried my best to explain it (hence this document - which contains a detailed appendix outlining why SSL is dangerous as it was the primary
focus of bikeshedded "but it'll add an extra layer of security")
i was intending to document the examples of other Distros, but the
bikeshedding degenerated into verbally-abusive behaviour and i was
so shocked that i terminated further planned development of the document
(and left the group).
this has left some of the thoughts which i outlined in my post unpublished.
the general idea was - and i would welcome contributions here (
http://lkcl.net/reports/wot/wot.tex - also see Makefile in the same dir)
the general idea was to add example Distros, explaining where they
break down, because they break one (or more) of the chain of integrity, referring clearly to the "Requirement" as a way to do so.
(and then clarifying the requirements further, in an iterative process)
for example Ubuntu violates at least Requirement 11, because the
size of the group comprising the ring-of-trust is too small, and the
integrity of the group is compromised because they may be threatened
with salary reductions or loss of employment if they don't do what
the Corporation demands. it sounds obvious once expressed, but
i can guarantee that it's not even remotely on the radar of the average
ubuntu user.
i do have to say that having a public document like this would go a
long way towards preventing some of the criticism that Debian receives
for "being slow to react" and "being too complex" or "not secure enough"
i've had discussions with NixOS developers recently, who genuinely
believe that Debian is vulnerable and NixOS is better because, their
words, "debian doesn't have reproducible builds."
rather embarrassingly i had to explain to them that the reason
why they're having an easy time of adding reproducible builds to
NixOS is because both debian and fedora originally did all the heavy
lifting, and have had reproducible builds for what... 8 years now?
those distros *paved the way*... oh and then didn't really talk about it
or promote it. hence why NixOS developers genuinely believe that they
are "the world's first secure reproducible build distro".
explaining to them that relying on github and unverified unsigned
git checkins is a bad idea (no commits and no packages are GPG-signed
in NixOS) took multiple round-trips, spanning over a week.
Also I like to add that reproducible builds are an excellent addition
to the mechanisms you are describing.
very true: they'd be part of the integrity-checking, down to the binary
level. interestingly (this from my Software Engineering training)
it'd be added to the section on Functional Specification, not
necessarily Requirements. if added to Requirements it would
be worded something like:
"Other Maintainers should be able to verify the full integrity
of a package by reproducing its contents from the original source"
the *implementation* of that - part of the Functional Specification -
would mention "reproducible builds" because that is *how* you
fulfil the Requirement.
i'd be delighted to receive a patch to the .tex file to add that:
please do also remember to add an appropriate Copyright notice
at the same time, should you choose to contribute.
http://lkcl.net/reports/wot/wot.tex
best,
l.
---
crowd-funded eco-conscious hardware:
https://www.crowdsupply.com/eoma68
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)