Re: Interest in ISO 27001 audit/certification for the Debian Project?
Simon Josefsson <simon@josefsson.org> writes:
> Russ Allbery <rra@debian.org> writes:
>> Simon Josefsson <simon@josefsson.org> writes:
>>> I think that is not the only possible scenario -- another one that I
>>> find at least reasonable, if not more likely, is that anyone who
>>> considered volunteering to implement this soon realized that there are
>>> fundamental aspects that would need to be addressed first, raised
>>> those concerns, did not find sufficient support or interest to address
>>> or talk about the concerns, and started to work on improving those
>>> issues elsewhere (if they at all cared to pursue it further,
>>> demotivation is a factor too).
>> Sure, I intended to include that in "not in a position to do that
>> work." Missing prerequisites is one of the reasons why someone may not
>> be in a position to do that work.
> Ah, I didn't realize the pool for volunteers you consider only include
> those who are in a position to do the work.
That's what "volunteer" means? If they can't do the work, by definition
they can't volunteer to do the work. I'm not sure I understand what point
you're trying to make.
> That is a small and probably rather busy set of people, and I couldn't
> blame them for not having time to implement everyone's pet wish. That to
> me suggests a systematic concern: that it is not possible to volunteer
> to do some work, and that it has to be performed by people who are in
> the right position.
Why is it not possible for any interested person to volunteer to do the
work? Obviously it's less work for some volunteers than others, and if you
aren't already up to speed in this area, it will require more effort. If
the problem involves changing C++ code and you don't know C++, it might
take a lot of effort! Also, socially, you may have to help relieve the
burdens of other volunteers sufficiently that they have time to answer
your questions.
In most cases, if the problem was trivial, we would have already solved
it. If it's not been done, that's usually a sign that some real effort is
required.
But this certainly seems *possible*. I don't see any reason why it would
be impossible; it just requires investment of time, willingness to relieve
other burdens for people so that your work is effort-neutral, and some
patience. Some volunteer tasks require more effort than others,
unsurprisingly.
Someone has to volunteer to do that work, though. No one is doing that. I
conclude that, at least at the moment, no one is in a position to put in
the effort to do the work. That's what happens in a volunteer project.
It's insufficient to have a good idea; you also have to find someone
willing to put in the actual effort into making the idea happen.
> The last sentence is certainly true. However I see some opposition to
> allowing people to do transparency work. Trixie could have shipped with
> the 'apt-verify' package that would have allowed users to ALSO verify
> upgrades using Sigstore or Sigsum, or other mechanisms. It would not
> have degraded or affected PGP verification, which would still be
> effective. It would not do anything for users that didn't install the
> apt-verify package. But the apt team added a 'Conflicts: apt-verify' to
> apt, effectively making 'apt-verify' uninstallable, and attempts to
> resolve the dispute has not lead anywhere.
> Definitely 'apt-verify' has limitations and is not a perfect solution,
> but at least it allows opt-in experimentation and some progress in this
> area. I've been using it on some of my machines for over a year,
> protecting upgrades through Sigstore transparency-logged signatures.
Security work often involves tricky trade-offs that require incorporating
iterative feedback from people who disagree with the initial approach or
have other non-security-related concerns. I'm sure you know this; you've
worked on security projects for a long time now. You can't just bulldoze
those sorts of objections and have a successful security project, because
security projects are almost always also social projects. You have to
understand the objections and either find a workable compromise or, if you
can't and you think the objections are simply wrong, escalate.
This is part of why security work is hard! I would never argue that it's
not hard; I also have done a lot of security work. This is part of why
it's difficult to find volunteers to do security projects, and if that's
your point, then sure, I agree. But Debian is not going to magically
become the place where security projects don't require understanding
competing trade-offs and concerns and addressing them with patience and
persistence. That's pretty universal.
I don't know very much about apt-verify in particular. I think I vaguely
remember there was some previous argument that I ignored. If I dove into
some previous discussion of it and have forgotten that completely, I'm
going to be very embarrassed, but a search of my sent mail seems to
indicate that's not the case.
It looks like the main discussion is at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061185
Based on a quick glance at that discussion, it looks like there were three
major objections:
* The project is not maintained or endorsed by the apt team, so they
objected to the apt-verify name. This seems at least arguably
reasonable, and the fix is trivial: just rename it. If is, as you say
above (paraphrasing), an imperfect experiment, what does it matter what
it's called right now? You can always rename it later when it's less
experimental and has more consensus. Seems like an obvious compromise.
* It depends on deprecated and unsupported apt interfaces. I get the
objection here but personally I would argue that the apt team should
just file an RC bug against it for that reason. That by itself doesn't
feel like it would warrant a conflict. (I do agree that I would be
dubious about shipping something to stable in that state, so unless I'm
missing something, I think your statement that we could have shipped
this with trixie is technically correct but it wouldn't have met my
quality bar.)
* This verification approach cannot be supported in apt's sandbox model
and will need work to enhance the sandboxing so that verification hooks
like this can be added. I read Julian's message as essentially saying
that this is a ton of work that's going to take a long time if he's the
only one doing it, but he actively welcomes help to get there faster.
So... you could take Julian up on his offer! You could help him unblock
experimentation with signature verification hooks, and then we will all
have an apt that allows more experimentation in this area, which I think
is your goal. But that of course will require effort. Or you could propose
some different approach, or if you think the analysis of the apt
maintainers is technically incorrect (I do not have the knowledge to judge
this), you could point that out, or escalate to the Technical Commitee.
It looks like your reply is at:
https://lists.debian.org/deity/2024/01/msg00060.html
I'm not sure I understand this message, since it doesn't feel like it
addresses the concerns raised by the apt developers and instead tries to
start a different architectural discussion that is at least partly
addressed by Julian's message. I would have found this reply kind of
baffling if I were an apt developer. Maybe you didn't see Julian's message
at all? (Your message makes somewhat more sense if that's the case.)
Anyway, so far as I can tell, that message didn't receive a response,
although I'm not sure if I'm searching correctly. If that's correct, I'm
not that surprised since it doesn't seem to engage with the previous
messages, or (probably even more likely) people set it aside to respond to
later and then later never happened.
(I'm not going to think about how many messages I've done that with.)
The way I would summarize this from my admittedly very limited perspective
formed from just a half-hour of reading is that you wrote an interesting
but not (from the perspective of the apt maintainers) supportable hack
that works for you and uploaded it to the archive, the apt maintainers
objected for various reasons, and then added a Conflicts when you didn't
reply to their objections. (Again, I may be missing some other
discussion.)
This seems basically reasonable? A Conflicts is pretty harsh and maybe an
RC bug would have been sufficient, but I can understand it if they didn't
get a reply.
Regardless, I think I'm missing what you are calling "opposition to
allowing people to do transparency work." There's none of that in the
messages above, so presumably there was some other discussion that I was
unable to find.
I know apt-verify was an aside, but my point is that this is exactly what
I'm talking about when I say it needs volunteer effort. Security and
transparency work is not trivial and has a lot of reputational and process
implications for other teams who are often quite busy, so it's generally
not the sort of thing that you can just do by yourself. It requires
talking to people and that may require helping them with other work in
exchange for that effort from them. It may also involve some serious
effort to find compromises between "let's just start with this hack and
see if it works" and "let's boil the ocean of this design area first,"
which is a *very common* early obstacle for security work.
In Debian, this is generally harder than it probably should be. There too,
if that's your point, I at least somewhat agree with you. tag2upload, IMO,
required a lot more discussion than ideally it should have, and also
involved more escalation than I think ideally should have been involved.
(I hope that phrasing is neutral enough to convey that I could criticize
how nearly everyone handled it, definitely including myself.) But we got
there in the end; that's part of doing the work.
If we can find ways to make work like that easier and less fraught, I'm
all in favor! This would make Debian much healthier. But changing things
maintained by busy people with strong opinions is, in general, just not
going to be trivial to do, and some sustained effort will be required.
TL,DR: I think it's harder to do work that requires interteam coordination
in Debian than it should be, and I think we hit confrontational failure
modes more often than we should for a whole lot of reasons. But I don't
think any of this is specific to transparency or security projects. It's
just a general Debian problem, not opposition to work on this problem
area. If we can improve the Debian workflow in general, that will also
improve this case; until we do, this is part of what doing the work means.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: