Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #119636 > unrolled thread

Interest in ISO 27001 audit/certification for the Debian Project?

Back to article view | Back to linux.debian.devel

Contents

  Interest in ISO 27001 audit/certification for the Debian Project? Farruco <farruco@envs.net> - 2025-11-18 10:50 +0100
    Re: Interest in ISO 27001 audit/certification for the Debian Project? Jonathan Kamens <jik@kamens.us> - 2025-11-18 15:30 +0100
      Re: Interest in ISO 27001 audit/certification for the Debian Project? Simon Josefsson <simon@josefsson.org> - 2025-11-18 15:40 +0100
        Re: Interest in ISO 27001 audit/certification for the Debian Project? Russ Allbery <rra@debian.org> - 2025-11-18 20:00 +0100
          Re: Interest in ISO 27001 audit/certification for the Debian Project? Simon Josefsson <simon@josefsson.org> - 2025-11-19 14:20 +0100
            Re: Interest in ISO 27001 audit/certification for the Debian Project? Russ Allbery <rra@debian.org> - 2025-11-19 19:40 +0100
              Re: Interest in ISO 27001 audit/certification for the Debian Project? Simon Josefsson <simon@josefsson.org> - 2025-11-20 06:30 +0100
                Re: Interest in ISO 27001 audit/certification for the Debian Project? Russ Allbery <rra@debian.org> - 2025-11-20 09:10 +0100
                Re: Interest in ISO 27001 audit/certification for the Debian Project? Holger Levsen <holger@layer-acht.org> - 2025-11-20 10:00 +0100
              Re: Interest in ISO 27001 audit/certification for the Debian Project? Tollef Fog Heen <tfheen@err.no> - 2025-11-22 22:20 +0100
                Re: Interest in ISO 27001 audit/certification for the Debian Project? Russ Allbery <rra@debian.org> - 2025-11-22 22:50 +0100
                  Re: Interest in ISO 27001 audit/certification for the Debian Project? Tollef Fog Heen <tfheen@err.no> - 2025-11-23 14:10 +0100
                    Re: Interest in ISO 27001 audit/certification for the Debian Project? Jonathan Kamens <jik@kamens.us> - 2025-11-23 15:30 +0100
                      Re: Interest in ISO 27001 audit/certification for the Debian Project? Jonathan Kamens <jik@kamens.us> - 2025-11-23 16:20 +0100
                      Re: Interest in ISO 27001 audit/certification for the Debian Project? Colin Watson <cjwatson@debian.org> - 2025-11-23 16:20 +0100
    Re: Interest in ISO 27001 audit/certification for the Debian Project? Jeremy Stanley <fungi@yuggoth.org> - 2025-11-18 23:10 +0100
      Re: Interest in ISO 27001 audit/certification for the Debian Project? Farruco <farruco@envs.net> - 2025-11-19 17:30 +0100
        Re: Interest in ISO 27001 audit/certification for the Debian Project? Russ Allbery <rra@debian.org> - 2025-11-19 20:20 +0100
    Re: Interest in ISO 27001 audit/certification for the Debian Project? Marc Haber <mh+debian-devel@zugschlus.de> - 2025-11-19 13:50 +0100
      Re: Interest in ISO 27001 audit/certification for the Debian Project? Salvo Tomaselli <tiposchi@tiscali.it> - 2025-11-19 14:10 +0100

#119636 — Interest in ISO 27001 audit/certification for the Debian Project?

TL;DR: Does Debian (via SPI) have plans or interest in pursuing ISO 27001
certification for its development, maintenance, and operations? This
could bolster assurance for users amid supply chain risks.


Dear Debian Developers,

In an era of rising supply chain attacks (e.g., XZ Utils), downstream
users increasingly scrutinize the security of packaged software and of
the processes involved in their generation and maintenance. Debian not
only distributes an open source (non-commercial) product to the public
but also provides critical services to its developer community via the
project's IT infrastructure.

To strengthen and document their security posture, many of Debian's
peers undergo regular audits. ISO 27001 - a leading framework for
information security management systems (ISMS) - helps assess risks,
formalize controls and policies, and align internal processes with
relevant best practices. Examples include:

	* Canonical:
https://canonical.com/blog/canonical-achieves-iso-27001-certification
Quote from Canonical: "The certification demonstrates alignment with
cybersecurity standards that will further safeguard open source products
and services for use in the most demanding enterprise environments."

	* Red Hat:
https://access.redhat.com/compliance/isoiec-27001 - Covers key offerings
like OpenShift.

	* SUSE:
https://www.suse.com/support/security/certifications/ – Their global
operations under ISO 27001.

	* For contrast, Let's Encrypt:
It's not a legal entity (instead, it's an operation under the non-profit
corporation ISRG) and it lacks ISO 27001 certification, but meets annual
WebTrust audits required for publicly recognized CAs.

Debian, while not a legal entity, sits under SPI's non-profit corporate
umbrella, and ISO 27001 can scope to specific operations (per Clause
4.3). Therefore, certification could be issued to SPI but scoped to only
target Debian's development, maintenance, and operations.

Does the Debian Project have plans or interest in auditing/certifying
to ISO 27001? If not, are there alternative frameworks (e.g., SOC 2)
under consideration? I'd be happy to know.

-- 
Farruco.

[toc] | [next] | [standalone]

#119642

[Multipart message — attachments visible in raw view] — view raw

Speaking as someone who has been in the driver's seat for multiple ISO 
27001, SOC 2, and PCI DSS audits:

ISO 27001 certification for Debian would, in my opinion, be mostly 
pointless and would not bring nearly enough benefit to justify the 
significant cost in money, time, and effort. Four reasons:

1) Debian's infosec practices are leaps and bounds above those of most 
entities that have ISO 27001 certification. Getting audited will not 
help Debian significantly improve or become significantly more secure.

2) Individuals and entities all over the world are already using Debian. 
There is no evidence that Debian needs ISO 27001 certification to 
continue being used and useful.

3) Debian having ISO 27001 certification will do nothing to prevent 
supply chain attacks to its packages. There is nothing in Debian's 
current processes, or in any process changes Debian might make to pass 
an audit, that would have prevented the XZ Utils attack from making its 
way into Debian. There are simply too many software packages from two 
many sources in Debian to expect Debian to be responsible for vetting 
every single one to make sure that its real upstream maintainers haven't 
introduced malicious code.

4) Frankly, the primary reason any entity gets certified for ISO or SOC 
or PCI or whatever is because it needs the certification to compete in 
the marketplace. I don't think Debian has this problem.

   jik

On 11/18/25 4:44 AM, Farruco wrote:
> TL;DR: Does Debian (via SPI) have plans or interest in pursuing ISO 27001
> certification for its development, maintenance, and operations? This
> could bolster assurance for users amid supply chain risks.
>
>
> Dear Debian Developers,
>
> In an era of rising supply chain attacks (e.g., XZ Utils), downstream
> users increasingly scrutinize the security of packaged software and of
> the processes involved in their generation and maintenance. Debian not
> only distributes an open source (non-commercial) product to the public
> but also provides critical services to its developer community via the
> project's IT infrastructure.
>
> To strengthen and document their security posture, many of Debian's
> peers undergo regular audits. ISO 27001 - a leading framework for
> information security management systems (ISMS) - helps assess risks,
> formalize controls and policies, and align internal processes with
> relevant best practices. Examples include:
>
> 	* Canonical:
> https://canonical.com/blog/canonical-achieves-iso-27001-certification
> Quote from Canonical: "The certification demonstrates alignment with
> cybersecurity standards that will further safeguard open source products
> and services for use in the most demanding enterprise environments."
>
> 	* Red Hat:
> https://access.redhat.com/compliance/isoiec-27001 - Covers key offerings
> like OpenShift.
>
> 	* SUSE:
> https://www.suse.com/support/security/certifications/ – Their global
> operations under ISO 27001.
>
> 	* For contrast, Let's Encrypt:
> It's not a legal entity (instead, it's an operation under the non-profit
> corporation ISRG) and it lacks ISO 27001 certification, but meets annual
> WebTrust audits required for publicly recognized CAs.
>
> Debian, while not a legal entity, sits under SPI's non-profit corporate
> umbrella, and ISO 27001 can scope to specific operations (per Clause
> 4.3). Therefore, certification could be issued to SPI but scoped to only
> target Debian's development, maintenance, and operations.
>
> Does the Debian Project have plans or interest in auditing/certifying
> to ISO 27001? If not, are there alternative frameworks (e.g., SOC 2)
> under consideration? I'd be happy to know.
>

[toc] | [prev] | [next] | [standalone]

#119643

[Multipart message — attachments visible in raw view] — view raw

Jonathan Kamens <jik@kamens.us> writes:

> Speaking as someone who has been in the driver's seat for multiple ISO
> 27001, SOC 2, and PCI DSS audits:
>
> ISO 27001 certification for Debian would, in my opinion, be mostly
> pointless and would not bring nearly enough benefit to justify the
> significant cost in money, time, and effort. Four reasons:
>
> 1) Debian's infosec practices are leaps and bounds above those of most
> entities that have ISO 27001 certification. Getting audited will not
> help Debian significantly improve or become significantly more secure.

Debian's handling of the archive crypto key could definitely be
improved, and I'd be surprised if available public documentation of
Debian's processes around this would live up to ISO 27001 scrutiny or
even Debian's preference to not hide things from our users.

I agree with you that ISO 27001 certications are often pointless, but I
would disagree that Debian would not be improved by further
documentation and transparency work.  There is little assurance that the
archive private key isn't leaked by unknown key holders, or it may even
be generated on proprietary compromised devices.

/Simon

[toc] | [prev] | [next] | [standalone]

#119644

Simon Josefsson <simon@josefsson.org> writes:

> I agree with you that ISO 27001 certications are often pointless, but I
> would disagree that Debian would not be improved by further
> documentation and transparency work. There is little assurance that the
> archive private key isn't leaked by unknown key holders, or it may even
> be generated on proprietary compromised devices.

I think the key point here is that this is already work that we could do
if there were volunteers willing to do it. Based on the number of years
you've been raising this as an issue and the lack of results, I am
assuming that's the primary problem: No one in a position to do the work
is volunteering to do it.

Adding ISO 27001 to the mix seems very unlikely to improve that
fundamental problem. It would add a great deal of paperwork and process
that is not directly relevant to the specific problem you are identifying,
and that would take up even more volunteer time, precisely the resource
that is already missing.

If someone is volunteering to work on documentation and transparency of
key handling procedures, they can (and probably should) look at audit
frameworks for inspiration for how to do that work, but first we have to
find the person or people who are willing to do the work. That feels like
the hard part.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#119652

[Multipart message — attachments visible in raw view] — view raw

Russ Allbery <rra@debian.org> writes:

> Simon Josefsson <simon@josefsson.org> writes:
>
>> I agree with you that ISO 27001 certications are often pointless, but I
>> would disagree that Debian would not be improved by further
>> documentation and transparency work. There is little assurance that the
>> archive private key isn't leaked by unknown key holders, or it may even
>> be generated on proprietary compromised devices.
>
> I think the key point here is that this is already work that we could do
> if there were volunteers willing to do it. Based on the number of years
> you've been raising this as an issue and the lack of results, I am
> assuming that's the primary problem: No one in a position to do the work
> is volunteering to do it.
>
> Adding ISO 27001 to the mix seems very unlikely to improve that
> fundamental problem. It would add a great deal of paperwork and process
> that is not directly relevant to the specific problem you are identifying,
> and that would take up even more volunteer time, precisely the resource
> that is already missing.
>
> If someone is volunteering to work on documentation and transparency of
> key handling procedures, they can (and probably should) look at audit
> frameworks for inspiration for how to do that work, but first we have to
> find the person or people who are willing to do the work. That feels like
> the hard part.

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).

That pattern applies to Ubuntu, although I guess ISO 27001 on its own
may not have been the biggest motivation there.  Still, the end result
is that Ubuntu has ISO 27k and Debian hasn't.

(I guess the reference to "you" is not directly meant to me, but someone
else?  I don't recall bringing up ISO 27k before and personally I find
such certifications, like FIPS, generally more harmful than useful.
Some parts of ISO 27k bring up important topics, but you can become ISO
27k certified without really adressing the problems, and some of the
topics they bring up may imply worse technical solutions.)

/Simon

[toc] | [prev] | [next] | [standalone]

#119654

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.

> That pattern applies to Ubuntu, although I guess ISO 27001 on its own
> may not have been the biggest motivation there.  Still, the end result
> is that Ubuntu has ISO 27k and Debian hasn't.

I think we're both agreeing on ISO 27001.

I would expect the current state, since Ubuntu is (in part) the product of
a commercial company that wants to sell to the sorts of institutions that
care about ISO 27001 and therefore is willing to pay people to do the
tedious and annoying work of filling out all the paperwork required for
certification.

Debian is (presumably) not. It's not at all obvious to me, as someone who
has worked on ISO 27001 and other security certifications before, why
Debian would bother. The current certification state feels like an
excellent division of labor to me: The volunteer project works on the
things that are more interesting and enjoyable to do in one's spare time
or as targeted contract work, and the company attempting to make a
commercial product takes a snapshot of that work and then does all the
tedious and annoying certification paperwork filing and maintenance, which
often requires a full-time compliance team, external audits depending on
the specific certification, etc.

Certification compliance is not something I would ever work on without
being paid, personally. It is not enjoyable or fun; it's a job whose only
real benefit is the paycheck you get for doing it. That's of course just
my personal opinion; maybe someone out there finds filling out ISO 27001
paperwork a great way to spend a lazy Saturday afternoon.

> (I guess the reference to "you" is not directly meant to me, but someone
> else?  I don't recall bringing up ISO 27k before and personally I find
> such certifications, like FIPS, generally more harmful than useful.
> Some parts of ISO 27k bring up important topics, but you can become ISO
> 27k certified without really adressing the problems, and some of the
> topics they bring up may imply worse technical solutions.)

No, I mean you, but I was talking about the "I would disagree that Debian
would not be improved by further documentation and transparency work" part
of your message. You have been making this point for some time, and still
seem unhappy with the current state, so I assume that the basic problem is
lack of volunteer resources. That may include resources to work through
whatever underlying concerns people may have uncovered and figure out how
to address them within Debian's structure; that is, indeed, part of that
work. My point is that I don't think anyone is *opposed* to "further
documentation and transparency work." There are just a lot of things to do
in Debian and people work on the things they think are important or enjoy.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#119656

[Multipart message — attachments visible in raw view] — view raw

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 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.

>> (I guess the reference to "you" is not directly meant to me, but someone
>> else?  I don't recall bringing up ISO 27k before and personally I find
>> such certifications, like FIPS, generally more harmful than useful.
>> Some parts of ISO 27k bring up important topics, but you can become ISO
>> 27k certified without really adressing the problems, and some of the
>> topics they bring up may imply worse technical solutions.)
>
> No, I mean you, but I was talking about the "I would disagree that Debian
> would not be improved by further documentation and transparency work" part
> of your message. You have been making this point for some time, and still
> seem unhappy with the current state, so I assume that the basic problem is
> lack of volunteer resources. That may include resources to work through
> whatever underlying concerns people may have uncovered and figure out how
> to address them within Debian's structure; that is, indeed, part of that
> work. My point is that I don't think anyone is *opposed* to "further
> documentation and transparency work." There are just a lot of things to do
> in Debian and people work on the things they think are important or enjoy.

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.

/Simon

[toc] | [prev] | [next] | [standalone]

#119657

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/>

[toc] | [prev] | [next] | [standalone]

#119658

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 20, 2025 at 06:21:04AM +0100, Simon Josefsson wrote:
> The last sentence is certainly true.  However I see some opposition to
> allowing people to do transparency work.  

so what? there will always be some opposition.

As I see it transparency logs for Debian can be prototyped very well outside
of Debian, no need to be a DD or anything.

It "just" needs time and skills... I do intend to find time for this in 2026.
And be very glad if someone is quicker ;-D


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not the lockdown which is unbearable, but the virus.

[toc] | [prev] | [next] | [standalone]

#119673

]] Russ Allbery 

> Simon Josefsson <simon@josefsson.org> writes:

>> That pattern applies to Ubuntu, although I guess ISO 27001 on its own
>> may not have been the biggest motivation there.  Still, the end result
>> is that Ubuntu has ISO 27k and Debian hasn't.

Ubuntu doesn't have it, though. Canonical's ISMS is ISO27001 certified.
There's no mention of Ubuntu in the press release.

[...]

> Certification compliance is not something I would ever work on without
> being paid, personally. It is not enjoyable or fun; it's a job whose only
> real benefit is the paycheck you get for doing it. That's of course just
> my personal opinion; maybe someone out there finds filling out ISO 27001
> paperwork a great way to spend a lazy Saturday afternoon.

I'm obviously not going to tell you what you enjoy or not, but I think
that's a poor (but sadly quite common) way of doing compliance
work. Compliance work should be like running make check – it's a way of
testing that your procedures are actually as expected and provide
verification that the security properties you put into the system still
hold.  If it's compliance for compliance's sake, it'll be thrown out the
window at the first opportunity.

All that said, I don't think we should be doing 27001, SOC2 or
similar. We're not aligned in how we work and doing an audit including
audit trails and such is completely infeasible, even if we were able to
explain it to an auditor.  As an example, and as someone who holds some
keys in Debian (such as the cert used to sign uploads to MS for shim
signatures), I'd not be particularly interested in spending time proving
documenting or proving to an auditor what my security controls for that
key particular is.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#119674

Tollef Fog Heen <tfheen@err.no> writes:
> ]] Russ Allbery 

>> Certification compliance is not something I would ever work on without
>> being paid, personally. It is not enjoyable or fun; it's a job whose
>> only real benefit is the paycheck you get for doing it. That's of
>> course just my personal opinion; maybe someone out there finds filling
>> out ISO 27001 paperwork a great way to spend a lazy Saturday afternoon.

> I'm obviously not going to tell you what you enjoy or not, but I think
> that's a poor (but sadly quite common) way of doing compliance
> work. Compliance work should be like running make check – it's a way of
> testing that your procedures are actually as expected and provide
> verification that the security properties you put into the system still
> hold.  If it's compliance for compliance's sake, it'll be thrown out the
> window at the first opportunity.

I'm not sure I understand what you're characterizing as a poor way of
doing compliance work. Oh, maybe you're saying that compliance shouldn't
only be a paperwork exercise?

Sure, that's certainly true, and when I worked on compliance, it wasn't.
We built as much of compliance as possible into our software and automated
generating the information required for proof of compliance. The goal was
to ensure, wherever possible (it's not possible everywhere), that a
computer was enforcing the correct process rather than a human having to
remember it, and a computer was keeping all the necessary audit trails and
generating the compliance reports.

I think this was doing compliance properly? I don't think it was a poor
job. There was still a lot of paperwork (which, lucky for me, was mostly
done by other people).

Nonetheless, it was work, for which I was paid, and which was not
interesting or satisfying in its own right, and while some of it is simply
necessary to do a good job (similar to how writing a test suite can be
tedious but is necessary to do a good job of software development), a lot
of the necessary outputs (and audit meetings!) are just annoying or
involve effort to reward trade-offs that are hard to justify unless you
care about the compliance certification specifically.

> As an example, and as someone who holds some keys in Debian (such as the
> cert used to sign uploads to MS for shim signatures), I'd not be
> particularly interested in spending time proving documenting or proving
> to an auditor what my security controls for that key particular is.

See, right, this is exactly my point. I have done work like this before,
but it's not something I'm going to do for free, because it's tedious and
annoying. If we want some sort of make test for our procedures, which is
certainly a rational thing to want, we'll need to figure out some way to
do it that's less tedious and annoying than (at least my experience with)
audit and compliance frameworks.

There is to some extent a reason for why those audit and compliance
frameworks do things the way they do, and not all of it is an outgrowth of
formalism or bureaucracy. They probably do catch some things that less
formal and more streamlined approaches don't. But locking down those last
few percentage points of security is a lot of work that we are going to
have a pretty hard time finding someone to do for free. People who really
care about that should be prepared to pay for it, which also has
implications for who should be doing it and how to structure that work.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#119679

]] Russ Allbery 

> Tollef Fog Heen <tfheen@err.no> writes:
>> ]] Russ Allbery 
>
>>> Certification compliance is not something I would ever work on without
>>> being paid, personally. It is not enjoyable or fun; it's a job whose
>>> only real benefit is the paycheck you get for doing it. That's of
>>> course just my personal opinion; maybe someone out there finds filling
>>> out ISO 27001 paperwork a great way to spend a lazy Saturday afternoon.
>
>> I'm obviously not going to tell you what you enjoy or not, but I think
>> that's a poor (but sadly quite common) way of doing compliance
>> work. Compliance work should be like running make check – it's a way of
>> testing that your procedures are actually as expected and provide
>> verification that the security properties you put into the system still
>> hold.  If it's compliance for compliance's sake, it'll be thrown out the
>> window at the first opportunity.
>
> I'm not sure I understand what you're characterizing as a poor way of
> doing compliance work. Oh, maybe you're saying that compliance shouldn't
> only be a paperwork exercise?

Yes.  A bit like you probably shouldn't be writing tests for trivial
getters and setters in languages that use those to get a high test
coverage percentage, but rather having tests for places where there's
actual risk.

> Sure, that's certainly true, and when I worked on compliance, it wasn't.
> We built as much of compliance as possible into our software and automated
> generating the information required for proof of compliance. The goal was
> to ensure, wherever possible (it's not possible everywhere), that a
> computer was enforcing the correct process rather than a human having to
> remember it, and a computer was keeping all the necessary audit trails and
> generating the compliance reports.

Somehow, I'm unsurprised by you doing compliance work in a good way. :-)
But also, you seem not to be doing/have done it in a way where the only
benefit is the paycheck, but rather where it drives actual benefits.

[...]

> See, right, this is exactly my point. I have done work like this before,
> but it's not something I'm going to do for free, because it's tedious and
> annoying. If we want some sort of make test for our procedures, which is
> certainly a rational thing to want, we'll need to figure out some way to
> do it that's less tedious and annoying than (at least my experience with)
> audit and compliance frameworks.

Yup.  (I'm not sure I'd want to do it for Debian even if I were paid,
but that's both a separate discussion and obviously a position of
privilege to be able to hold.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#119680

[Multipart message — attachments visible in raw view] — view raw

On 11/23/25 8:02 AM, Tollef Fog Heen wrote:
> Somehow, I'm unsurprised by you doing compliance work in a good way. :-)
> But also, you seem not to be doing/have done it in a way where the only
> benefit is the paycheck, but rather where it drives actual benefits.

That is absolutely not what Russ said or meant.

What Russ said, quite clearly, is that he does not find compliance work 
enjoyable and would therefore not choose to do it on a volunteer basis.

At no point did he say there was no overall benefit to the compliance 
work he has done.

He said that the benefit _to him specifically_ that is necessary to 
motivate him to do compliance work, is being paid for it.

This is at least the second time in this thread you have misinterpreted 
things Russ said to inaccurately infer to him beliefs and opinions which 
he did not say and does not hold.

While Russ certainly doesn't need me to defend him, I personally would 
appreciate if you would make more of an effort to understand and not 
misstate other people's positions, because it is not only disrespectful 
to Russ, it is also disrespectful to the other members of this mailing 
list and a waste of their time to have to read and address inaccuracies.

Thanks.

[toc] | [prev] | [next] | [standalone]

#119681

[Multipart message — attachments visible in raw view] — view raw

On 11/23/25 10:16 AM, Colin Watson wrote:
> On Sun, Nov 23, 2025 at 09:29:13AM -0500, Jonathan Kamens wrote:
>> On 11/23/25 8:02 AM, Tollef Fog Heen wrote:
>>> Somehow, I'm unsurprised by you doing compliance work in a good way. 
>>> :-)
>>> But also, you seem not to be doing/have done it in a way where the only
>>> benefit is the paycheck, but rather where it drives actual benefits.
>>
>> That is absolutely not what Russ said or meant.
>>
>> What Russ said, quite clearly, is that he does not find compliance 
>> work enjoyable and would therefore not choose to do it on a volunteer 
>> basis.
>>
>> At no point did he say there was no overall benefit to the compliance 
>> work he has done.
>
> It feels like you've perhaps skipped over a "not" when reading 
> Tollef's email, or something like that?  I read that email in 
> precisely the opposite way to the way you seem to have read it. 

Indeed, I did! My apologies.

[toc] | [prev] | [next] | [standalone]

#119683

On Sun, Nov 23, 2025 at 09:29:13AM -0500, Jonathan Kamens wrote:
>On 11/23/25 8:02 AM, Tollef Fog Heen wrote:
>>Somehow, I'm unsurprised by you doing compliance work in a good way. :-)
>>But also, you seem not to be doing/have done it in a way where the only
>>benefit is the paycheck, but rather where it drives actual benefits.
>
>That is absolutely not what Russ said or meant.
>
>What Russ said, quite clearly, is that he does not find compliance 
>work enjoyable and would therefore not choose to do it on a volunteer 
>basis.
>
>At no point did he say there was no overall benefit to the compliance 
>work he has done.

It feels like you've perhaps skipped over a "not" when reading Tollef's 
email, or something like that?  I read that email in precisely the 
opposite way to the way you seem to have read it.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#119645

[Multipart message — attachments visible in raw view] — view raw

On 2025-11-18 09:44:10 +0000 (+0000), Farruco wrote:
>TL;DR: Does Debian (via SPI) have plans or interest in pursuing ISO 27001 
>certification for its development, maintenance, and operations?
[...]

What role do you expect SPI would play in this? (Asking as an 
officer/director since it may come down to me to support the 
endeavor from that side.)

Also, having been on point for writing entire ISO/IEC 27001 focused 
security policies and handbooks from scratch in a former life, I 
don't see how it would directly apply to Debian, there are a lot of 
operational controls which would need to be explained as irrelevant.

Perhaps more germane will be looking for alignment with 
recommendations that come out of ORC and OpenSSF as a response to 
the EU's harmonized standards for their Cyber Resilience Act, but 
those are still very much up in the air for the moment (I'm involved 
there as well, on the Spec Committee for the ORC WG).
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#119653

On 2025 Nov 18, 22:02, Jeremy Stanley wrote:
> 
> What role do you expect SPI would play in this? (Asking as an
> officer/director since it may come down to me to support the endeavor from
> that side.)

To answer the easier question first (SPI’s role): any certificate
would have to be issued to SPI as the only legal entity behind the Debian
Project. The role for SPI would indeed be mostly that of the “certified
organization” while the scope statement (Clause 4.3) would explicitly
limit the ISMS to Debian-specific infrastructure and processes. Therefore,
I don't think SPI itself would be dragged into heavy bureaucracy.

> Also, having been on point for writing entire ISO/IEC 27001 focused security
> policies and handbooks from scratch in a former life, I don't see how it
> would directly apply to Debian, there are a lot of operational controls
> which would need to be explained as irrelevant.

On applicability in a volunteer-heavy project: I completely share
the concern. Obviously, a large fraction of Annex A controls would
need to be answered as “not applicable” (especially the whole
HR/security-awareness sections, physical entry controls, supplier
contracts, etc.). Nonetheless, a sound, consistent, updated and properly
documented Information Security Management System can be of value in
any collective human endeavour in which cybersecurity is to be heeded,
and indeed the Debian Project can be argued to fall into that category.

> Perhaps more germane will be looking for alignment with recommendations that
> come out of ORC and OpenSSF as a response to the EU's harmonized standards
> for their Cyber Resilience Act, but those are still very much up in the air
> for the moment (I'm involved there as well, on the Spec Committee for the
> ORC WG).

I’m under no illusion that Debian is a typical commercial environment,
and I agree that a lot of Annex A would be N/A. My main motivation for
raising the question is the growing external pressure (CRA, NIS2, large
customers asking for evidence of supply-chain security) and the hope that
an external pair of eyes might surface a few blind spots that haven’t
been noticed (or voiced) internally. Whether full ISO 27001 certification
is the right answer - or whether something lighter (OpenSSF Scorecards,
SLSA level 3, or the emerging ORC recommendations you mentioned) is
more appropriate - is exactly what I wanted to understand from people
who know Debian (and ISO 27001) far better than I do.

So, reframing my original question now that I have better context: Do
you think a scoped, volunteer-friendly external audit (ISO 27001-based
or other framework) could still be useful, or is the project's security
already in a good enough shape to afford dismissing such?

Regards,

-- 
Farruco

[toc] | [prev] | [next] | [standalone]

#119655

Farruco <farruco@envs.net> writes:

> Nonetheless, a sound, consistent, updated and properly documented
> Information Security Management System can be of value in any collective
> human endeavour in which cybersecurity is to be heeded, and indeed the
> Debian Project can be argued to fall into that category.

This is one of those statements that is ubiquitous in compliance work to
justify the effort that goes into preparing this document. I think a lot
of compliance professionals truly believe this. However, as someone
adjacent but not part of the process, I am dubious. I don't think there's
all that much hard evidence that this is true.

I think there is much more evidence that an organzation that is capable of
writing Information Security Management System documentation is more
likely to be able to maintain good security. But that's not the same
thing; the causality goes in the other direction. Having full ISO 27001
documentation is a form of effort-signaling: You're showing that you care
enough about security to go through the tedium of maintaining formal
documentation. This does say something about how much you organizationally
value security, or at least the *appearance* of security (there are
criminal enterprises with ISO 27001 certifications), but it's not the only
way to do that.

It is certainly true that having documentation and organizational best
practices is fairly universally of value. But it is not at all obvious to
me that casting that documentation in the specific format of Information
Security Management System documentation has much value except for getting
compliance certifications. I suppose there's some benefit in skimming over
the list of things to document to make sure one is not missing something
obvious, but I can almost guarantee that if one then translates one's
documentation into that format, it will quickly become useless.

It's far more important that the documentation be:

- simple and easy to understand;
- easily and quickly maintanable so that it is kept up-to-date; and
- actually followed.

This is more likely if there is a minimum of boilerplate, as little
formality as it is possible to get away with, and a willingness to let the
little things drop rather than trying to comprehensively document
everything and thus ensure the documentation almost immediately becomes
out of date and therefore not trustworthy.

> So, reframing my original question now that I have better context: Do
> you think a scoped, volunteer-friendly external audit (ISO 27001-based
> or other framework) could still be useful, or is the project's security
> already in a good enough shape to afford dismissing such?

Yes, absolutely. External audits have value; a fresh pair of eyes often
notices things that you've stopped noticing. And taking a moment to think
through a list of possible risks, sort them, and write down some solid
documentation for how we're addressing the top few with checklists for
critical operations (if they don't already exist) is generally useful for
any project.

More useful than what people are already doing? Probably not! Debian does
not have lots of people, particularly people who already have the
knowledge of Debian required to do this sort of work, sitting around bored
and idle. But if someone said "I'm going to join one of the relevant teams
and help them with their existing work while writing documentation of
Debian's security practices, making sure that I do enough other work that
the impact on existing members is at least neutral," I would be entirely
in favor. Sounds great!

I would definitely not say that the project's security is in good enough
shape that I would dismiss something like this! I don't think our security
is *awful*, but it is certainly on the list of things that we could be
doing better. (It's a long list; making a distribution is a lot of work
and resources are scarce.)

I think the critical thing to avoid is any approach that would make
existing volunteers have to deal with certification paperwork if they
aren't actively excited to do that, because a whole lot of people are
going to have the same reaction that I have: No, this is the kind of work
that I only do for a paycheck, and Debian is not in a position to provide
my paycheck.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#119650

On Tue, Nov 18, 2025 at 09:44:10AM +0000, Farruco wrote:
>TL;DR: Does Debian (via SPI) have plans or interest in pursuing ISO 27001
>certification for its development, maintenance, and operations? This
>could bolster assurance for users amid supply chain risks.

In my paid work, the work that I need to do do pay for housing and food, 
I have to jump through uncomfortable burning hoops. I have to present my 
ideas in front of committees full of people who don't have the knowledge 
or expertise to judge my ideas, but they still do. This has already 
taken the fun from my paid work 20 years ago.

As an unpaid volunteer, I do HATE the idea of the same hoops being 
placed inside Debian.

"Enterprise IT is like IT, just without the fun".

Going for this (or another) certification will take the fun out of 
Debian as well. Please don't. Debian doesn't need to sell anything.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

#119651

I completely agree.

It's also a reason why I've decided to not implement ssfscorecards
crap in my personal projects.

If some corporation that wants to sell to the USA army or whatever
needs some compliance done, it won't be happening for free.

I think it is important to resist these pressures that ultimately come
from wealthy corporations trying to make us work for free.

So I'm against the idea of getting certified in principle. (I'm not
necessarily against the idea of improving the processes we use, but
only if there is no increase in workload).

Best

Il giorno mer 19 nov 2025 alle ore 13:39 Marc Haber
<mh+debian-devel@zugschlus.de> ha scritto:
>
> On Tue, Nov 18, 2025 at 09:44:10AM +0000, Farruco wrote:
> >TL;DR: Does Debian (via SPI) have plans or interest in pursuing ISO 27001
> >certification for its development, maintenance, and operations? This
> >could bolster assurance for users amid supply chain risks.
>
> In my paid work, the work that I need to do do pay for housing and food,
> I have to jump through uncomfortable burning hoops. I have to present my
> ideas in front of committees full of people who don't have the knowledge
> or expertise to judge my ideas, but they still do. This has already
> taken the fun from my paid work 20 years ago.
>
> As an unpaid volunteer, I do HATE the idea of the same hoops being
> placed inside Debian.
>
> "Enterprise IT is like IT, just without the fun".
>
> Going for this (or another) certification will take the fun out of
> Debian as well. Please don't. Debian doesn't need to sell anything.



-- 
Salvo Tomaselli

I difensori della morale tradizionale sono raramente persone di cuore. Si è
tentati di pensare che essi si servano della morale come di legittimo sfogo
al loro desiderio di fare del male agli altri.
               -- Bertrand Russell, Perché non sono cristiano. 1957

http://ltworf.github.io/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web