Re: [RFC] General Resolution to deploy tag2upload
On Thu, 13 Jun 2024 at 14:34, Timo Röhling wrote: > > Hi, > > * Luca Boccassi [2024-06-13 14:23]: > >As far as I understand in the current proposal the trigger is a > >webhook running on Salsa after a push - have you considered instead > >having the trigger be a stage in the salsa-ci pipeline, that would run > >after the previous stages have completed successfully? > I hate that idea. From past experience, the Salsa CI pipeline is > slower and much more flaky than the buildds, so I'm not going to > spend several hours (and retries) per upload waiting to see if the > Salsa CI deemed my upload worthy. Pipeline stages are by definition locally controlled, as the configuration lives in the git repository it runs for, so a maintainer can disable some or all of them on your repositories. >From past experience, the Salsa CI pipeline has been a huge boon, finding issues that would have otherwise been missed, and ensuring everything goes under the same degree of testing, regardless of where it comes from. Not to mention the massive time saver it is: just push and come back later and see the result, instead of driving things manually.
Re: [RFC] General Resolution to deploy tag2upload
On Thu, 13 Jun 2024 at 14:49, Ian Jackson
wrote:
>
> Timo Röhling writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > Luca Boccassi [2024-06-13 14:23]:
> > >As far as I understand in the current proposal the trigger is a
> > >webhook running on Salsa after a push - have you considered instead
> > >having the trigger be a stage in the salsa-ci pipeline, that would run
> > >after the previous stages have completed successfully?
> >
> > I hate that idea. From past experience, the Salsa CI pipeline is
> > slower and much more flaky than the buildds, so I'm not going to
> > spend several hours (and retries) per upload waiting to see if the
> > Salsa CI deemed my upload worthy.
>
> I hope Luca wasn't suggesting that Salsa CI as a blocker ought to be
> mandatory. Like so many things in this space, some people love what
> others hate.
I was not, I wasn't suggesting to make this a hard requirement, as you
say that's more complicated. Merely moving the fire-and-forget webhook
as the last stage of the pipeline, as the default
setting/setup/config/whatever. This is not to provide strong
guarantees, but merely an easy default that encourages a QA pass
first. Then maintainers can override the pipeline config and skip it,
if they don't want it for any reason. If it was the default, I suspect
de-facto the majority of uploads would go through it, and we would
gain in quality, on average (exceptions apply, etc etc).
Re: [RFC] General Resolution to deploy tag2upload
On Thu, 13 Jun 2024 at 12:47, Ian Jackson
wrote:
>
> Andreas Tille writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > That means some package build process is done before the source
> > package is forwarded to dak and sends some e-mail back?
>
> Only a source package build.
As far as I understand in the current proposal the trigger is a
webhook running on Salsa after a push - have you considered instead
having the trigger be a stage in the salsa-ci pipeline, that would run
after the previous stages have completed successfully? IE, like we can
do today with aptly or pages publishing, for example. What runs in the
pipeline is still under the control of the individual repo
maintainers, but the default would mean having this additional CI
step, which I think is what Andreas is hinting at, but solve it on the
other end of the pipeline - at the beginning, rather than at the end.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 22:35, Joerg Jaspert wrote: > > On 17258 March 1977, Luca Boccassi wrote: > > >> Whatever end goals some individuals may have is *NOT* a good base to > >> decide on how a technical implementation for Debian should be. > > >> If it turns out that this new thingie makes Salsa entirely > >> unneccessary, > >> then so be it. Good for us. > > >> I highly doubt this will happen. The dgit stuff only implements a > >> small > >> subset of features. The BTS does *not* provide what Salsa issues do. > >> There isn't anything even near to do what MRs do. CI integration? > >> Even > >> less so. No idea why anyone should fear this dgit thing will lead to > >> Salsa getting turned off, at this point. > > >> But really, if we end up getting something that makes an installation > >> of > >> gitlab unneccessary, then yay, party. It is not something to be > >> feared. > > > So in other words, I am 100% right to worry about this being the thin > > end of the wedge that some will use to try and kill Salsa. Sounds like > > below NoTA if it goes to GR for anybody who, like me, doesn't want > > Salsa to be jeopardised, then. > > WTF is up with you? Honest question. I just explained, in a load of > words, that this thing is *really* unlikely to provide whatever it needs > to replace Salsa, as there is basically nothing actually providing the > features Salsa provides. And your conclusion is more "trying to kill > Salsa"? You _literally_ just wrote: > If it turns out that this new thingie makes Salsa entirely unneccessary, then so be it. Good for us. > But really, if we end up getting something that makes an installation of gitlab unneccessary, then yay, party. It is not something to be feared. Not even an hour ago. How can you expect someone to reach any _other_ conclusion? WTF right back at you.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 22:26, Jonas Smedegaard wrote: > > Quoting Luca Boccassi (2024-06-12 22:00:04) > > On Wed, 12 Jun 2024 at 15:20, Jonas Smedegaard wrote: > > > > > > Quoting Luca Boccassi (2024-06-12 15:27:36) > > > > On Wed, 12 Jun 2024 at 14:15, Jonas Smedegaard wrote: > > > > > You apparently find it equally sensible, specifically as a security > > > > > measure, a) apply ACLs on an otherwise massively > > > > > multi-user-write-access > > > > > host and b) use a separate far-less-featured host. > > > > > > > > > > You claim that both setups have equal vulnerabilities. > > > > > > > > No, I claim they have different sets of vulnerabilities, disadvantages > > > > and advantages, and that both can provide the required feature: > > > > disallow force pushes/deleting tags. The hardest thing with security > > > > is that it requires a constant, ongoing effort, that will never end, > > > > and will only get harder. A widely used software like Gitlab is better > > > > for this, as is a widely used kernel like Linux. Or are you suggesting > > > > such a server should run on Hurd, given it's far-less-featured and > > > > thus has a much smaller attack surface than Linux? > > > > > > No, I am not suggesting the use of the Hurd here, and I am having a hard > > > time assuming good faith with the potential undertones of that question. > > > > > > To answer your convoluted question, I am suggesting that Salsa and > > > tag2upload has very different needs (multi-user write versus multi-user > > > append-only, drastically simplified), and consequently to not argue that > > > reuse of Salsa for hosting tag2upload is a security benefit. > > > > The argument is about attack surface, number of features, size of code > > base, auditability, etc. If you make that argument about the git stack > > running on a server, then the same argument applies for every other > > component in the same server that interact in any way with the > > payload(s) - kernel, libc, compilers, etc. Otherwise you are just > > cherrypicking what is convenient, and ignoring what is not. If Gitlab > > can't be used in a security-relevant component because it's too big to > > audit, then so are the Linux kernel and GCC. > > My point above, reframed to your new context, is that regardless of how > overwhelmingly large the attack surface of GCC+linux is, the attack > surface of GCC+linux+Gitlab is much larger, while that of > GCC+linux+tag2upload is little larger. The attack surface of GCC+linux+tag2upload is orders of magnitude larger than that of TCC+hurd+tag2upload. Are you going to advocate for that switch to happen? If not, why? Why do you think it's worth to deprecate Salsa because of its much larger attack surface, but it's not worth deprecating Linux and GCC for their demonstrably much larger attack surfaces? Could it be, maybe, perhaps, that a superficial comparison of perceived attack surfaces alone is not really a good metric to make a decision? > > My argument is that having a single system is beneficial for > > maintenance costs (fewer platforms, fewer moving parts), for security > > (components in widespread usage with heavy commercial backing spending > > the big to ensure it's not completely borken), and for > > rationalizing and avoiding duplication. > > Ok, if your argument is no longer that "the same setup can be achieved > with repository ACLs, and it would have the same vulnerability" but that > security+economy+maintenance combined makes your previous security-only > point less relevant to discuss, then I have nothing sensible to > contribute to this new path of yours. My argument has always been the same, which is: a custom forge is not needed to satisfy the requirement that force pushes/deleting tags is disallowed to users, which is what the design document uses to justify its choice as I understand it. If you understood something else from my point, then I'm afraid you were simply mistaken.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 22:08, Joerg Jaspert wrote: > > On 17258 March 1977, Luca Boccassi wrote: > > > And I think it is very much relevant, given the obvious end goal of > > some individuals is to kill Salsa, which this proposal - as it stands > > - would facilitate. > > Whatever end goals some individuals may have is *NOT* a good base to > decide on how a technical implementation for Debian should be. > > If it turns out that this new thingie makes Salsa entirely unneccessary, > then so be it. Good for us. > > I highly doubt this will happen. The dgit stuff only implements a small > subset of features. The BTS does *not* provide what Salsa issues do. > There isn't anything even near to do what MRs do. CI integration? Even > less so. No idea why anyone should fear this dgit thing will lead to > Salsa getting turned off, at this point. > > But really, if we end up getting something that makes an installation of > gitlab unneccessary, then yay, party. It is not something to be feared. So in other words, I am 100% right to worry about this being the thin end of the wedge that some will use to try and kill Salsa. Sounds like below NoTA if it goes to GR for anybody who, like me, doesn't want Salsa to be jeopardised, then.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 22:01, Joerg Jaspert wrote: > > On 17258 March 1977, Luca Boccassi wrote: > > > > > "My security recommendation in this case is therefore to centralize > > the risk as much as possible, moving it off of individual uploader > > systems with unknown security profiles and onto a central system that > > can be analyzed and iteratively improved." > > > So I don't think this is a good argument. One system is better than > > two. And we need to secure all of it anyway, as Salsa is a component > > of the solution anyway. > > Nah. Without having looked through the dgit source - having a system > beside salsa do this for Debian is much preferable. > > The gitlab for salsa is > a.) forcing us to follow a way that does *not* fit how Debian works for > uploads I have no idea what this means, sorry. > b.) a codebase so much larger and made out of so many more components > than all of this proposals code combined together, it will be *worse*. > I mean, look at the security history of Gitlab. Sure, they are fast in > fixing. But they are *constantly* fixing things up with "critical > release, apply ASAP". You can take that paragraph, do s/Gitlab/Linux kernel/ and it would still 100% apply. So do you propose that this additional forge runs on Hurd then? It's got no security advisories! A nice and clean security history.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 21:32, Russ Allbery wrote: > > Luca Boccassi writes: > > > But you don't push to snapshot, it's just a backup method, it doesn't > > take any input from DDs (AFAIK? Am I wrong?). Given > > https://browse.dgit.debian.org/ exists and has tons of stuff already, > > and this proposal for tag2upload doesn't exist yet, I gather that dgit > > is already a thing that is used independently of tag2upload? > > Correct. I've been using dgit to upload my packages for years now. The > packages are all maintained on Salsa. dgit push-source (the command to > upload a package) both pushes to the dgit-repos server and runs dput, > along with a few other things including source package construction and > signing. > > (dgit, the command-line tool, is independent of the tag2upload server. > You do not have to use dgit to use tag2upload.) > > > So I don't think this analogy works. One couldn't say "let's remove > > archive.debian.org, just push to snapshot.debian.org", but one could say > > "let's remove salsa.debian.org, just push to dgit.debian.org". > > In what sense could one say that? What do you think pushing to > dgit.debian.org would do? I think you have some confusion here about what > the dgit-repos server is for and what it does, but I'm having a hard time > figuring out the exact source of the confusion. > > If you're saying that if one doesn't care about making work in progress > available, doesn't want pull requests, doesn't want multiple people to be > able to work on a package together, and doesn't want CI, but only and > exclusively wants a Git server to archive a record of what Git trees were > uploaded as source packages, one could use only the dgit-repos server and > not Salsa, then yes, that's true. Yes, that's the argument - all Salsa features are bad and "bloat": issues are bad, teams are bad, CIs are bad, merge requests are bad, the only thing needed is to push&pull to some git backend, everything else is bad and unneeded.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 17:46, Russ Allbery wrote: > > Luca Boccassi writes: > > > As per the security review just shared, admin access to Salsa allows > > to push commits anyway which would get uploaded just the same, > > I'm not sure that I understand what you're saying here, but if I did > understand this correctly, no, this is not correct. My security review > says the exact opposite of this: admin access to Salsa does not allow you > to bypass the tag2upload checks or upload a source package. Probably "push commits anyway" was a wrong oversimplification, what I was referring to was all the various "someone with admin access on Salsa" mentions on the document you shared.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 19:24, Russ Allbery wrote: > > "Adam D. Barratt" writes: > > On Wed, 2024-06-12 at 10:43 -0700, Russ Allbery wrote: > > >> There was more confusion about this point than I had anticipated, so I > >> want to emphasize that the dgit-repos server is not a forge, is not a > >> competitor to Salsa, doesn't replace Salsa in any way, and is not > >> something that people interact with the way that they interact with > >> Salsa. It's much closer to a Git equivalent of archive.debian.org: a > >> persistent historical record accessible via the Git protocol and (as I > >> discovered during this thread) a cgit web interface. > > > In that sense, it's more like snapshot.debian.org, I think? > > Yes, apologies, that's a much better analogy. But you don't push to snapshot, it's just a backup method, it doesn't take any input from DDs (AFAIK? Am I wrong?). Given https://browse.dgit.debian.org/ exists and has tons of stuff already, and this proposal for tag2upload doesn't exist yet, I gather that dgit is already a thing that is used independently of tag2upload? I mean, that's how it was explained to me yesterday anyway. So I don't think this analogy works. One couldn't say "let's remove archive.debian.org, just push to snapshot.debian.org", but one could say "let's remove salsa.debian.org, just push to dgit.debian.org".
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 15:20, Jonas Smedegaard wrote: > > Quoting Luca Boccassi (2024-06-12 15:27:36) > > On Wed, 12 Jun 2024 at 14:15, Jonas Smedegaard wrote: > > > You apparently find it equally sensible, specifically as a security > > > measure, a) apply ACLs on an otherwise massively multi-user-write-access > > > host and b) use a separate far-less-featured host. > > > > > > You claim that both setups have equal vulnerabilities. > > > > No, I claim they have different sets of vulnerabilities, disadvantages > > and advantages, and that both can provide the required feature: > > disallow force pushes/deleting tags. The hardest thing with security > > is that it requires a constant, ongoing effort, that will never end, > > and will only get harder. A widely used software like Gitlab is better > > for this, as is a widely used kernel like Linux. Or are you suggesting > > such a server should run on Hurd, given it's far-less-featured and > > thus has a much smaller attack surface than Linux? > > No, I am not suggesting the use of the Hurd here, and I am having a hard > time assuming good faith with the potential undertones of that question. > > To answer your convoluted question, I am suggesting that Salsa and > tag2upload has very different needs (multi-user write versus multi-user > append-only, drastically simplified), and consequently to not argue that > reuse of Salsa for hosting tag2upload is a security benefit. The argument is about attack surface, number of features, size of code base, auditability, etc. If you make that argument about the git stack running on a server, then the same argument applies for every other component in the same server that interact in any way with the payload(s) - kernel, libc, compilers, etc. Otherwise you are just cherrypicking what is convenient, and ignoring what is not. If Gitlab can't be used in a security-relevant component because it's too big to audit, then so are the Linux kernel and GCC. My argument is that having a single system is beneficial for maintenance costs (fewer platforms, fewer moving parts), for security (components in widespread usage with heavy commercial backing spending the big to ensure it's not completely borken), and for rationalizing and avoiding duplication.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 15:34, Ian Jackson
wrote:
>
> Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > And I think it is very much relevant, given the obvious end goal of
> > some individuals is to kill Salsa, which this proposal - as it stands
> > - would facilitate.
>
> Gosh. Are you serious?
>
> For the avoidance of doubt: I'm a fan of gitlab and of Salsa.
> I don't want it killed.
I did not say you do! Nor did I say it was intentional. I am saying
that a few people do (and you know this), and I am worried that this
proposal could be taken advantage of for that purpose. I am not saying
nor implying nor suggesting nor thinking that the
proposers/developers/maintainers of tag2upload want to do that. Hope
this clarifies any misunderstandings, sorry for not being clear the
first time.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 14:15, Jonas Smedegaard wrote:
>
> Quoting Luca Boccassi (2024-06-12 14:55:13)
> > On Wed, 12 Jun 2024 at 13:47, Jonas Smedegaard wrote:
>
> [...]
>
> > > > > Luca Boccassi writes ("Re: [RFC] General Resolution to deploy
> > > > > tag2upload"):
> > > > > > As far as I can tell, from what was shared in these documents, the
> > > > > > security feature needed is an append-only repository, with
> > > > > > safeguards
> > > > > > that an individual developer cannot bypass. As far as I can tell,
> > > > > > the
> > > > > > same setup can be achieved with repository ACLs, and it would have
> > > > > > the
> > > > > > same vulnerability: an admin with full access to the server can
> > > > > > bypass
> > > > > > such measures, in either case. Is there something else I am missing?
>
> [...]
>
> > > I read the analysis more that two systems is better than one thousand
> > > systems.
> > >
> > > I.e. centralizing (compared to building done on developers' systems)
> > > to a system that can be analyzed (which Gitlab is quite a challenge
> > > to do).
> >
> > "centralize the risk as much as possible" applies to both cases, as
> > does the justification for it. And again, Salsa is already part of the
> > solution, so this argument doesn't seem very strong to me.
>
> No, not centralizing as much as possible, only as much as sensible.
That's not what it says though. If you have an alternative security
review, please share it in its entirety, and it can be discussed.
> You apparently find it equally sensible, specifically as a security
> measure, a) apply ACLs on an otherwise massively multi-user-write-access
> host and b) use a separate far-less-featured host.
>
> You claim that both setups have equal vulnerabilities.
No, I claim they have different sets of vulnerabilities, disadvantages
and advantages, and that both can provide the required feature:
disallow force pushes/deleting tags. The hardest thing with security
is that it requires a constant, ongoing effort, that will never end,
and will only get harder. A widely used software like Gitlab is better
for this, as is a widely used kernel like Linux. Or are you suggesting
such a server should run on Hurd, given it's far-less-featured and
thus has a much smaller attack surface than Linux?
> I disagree. I think you are mistaken - and no, it is totally irrelevant
> for this accusation whether or not I am a fan of Salsa, and whether or
> not I represent a loud or silent minority or majority. This is not about
> me.
And I think it is very much relevant, given the obvious end goal of
some individuals is to kill Salsa, which this proposal - as it stands
- would facilitate.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 13:47, Jonas Smedegaard wrote:
>
> Quoting Luca Boccassi (2024-06-12 14:40:01)
> > On Wed, 12 Jun 2024 at 12:52, Ian Jackson
> > wrote:
> > >
> > > Luca Boccassi writes ("Re: [RFC] General Resolution to deploy
> > > tag2upload"):
> > > > As far as I can tell, from what was shared in these documents, the
> > > > security feature needed is an append-only repository, with safeguards
> > > > that an individual developer cannot bypass. As far as I can tell, the
> > > > same setup can be achieved with repository ACLs, and it would have the
> > > > same vulnerability: an admin with full access to the server can bypass
> > > > such measures, in either case. Is there something else I am missing?
> > >
> > > There is also an assurance question. Salsa is running gitlab, which
> > > is an extremely complicated piece of software with very many features.
> > > Any one of those features (which are constantly changing) offers an
> > > opportunity for compromise of Salsa. Also, we don't have the
> > > resources to audit all the code comeing from gitlab upstream.
> > >
> > > The attack surface of the dgit repos server is much smaller. Its
> > > supply chain integrity is much better. So it is much less likely to
> > > be compromised. (Also, diversity of implementation is helpful.)
> >
> > Given we had a very well done and professional security review (thanks
> > Russ!), I think we should defer to that and take it into serious
> > consideration, and its conclusion seems quite clear to me in this
> > regard:
> >
> > "My security recommendation in this case is therefore to centralize
> > the risk as much as possible, moving it off of individual uploader
> > systems with unknown security profiles and onto a central system that
> > can be analyzed and iteratively improved."
> >
> > So I don't think this is a good argument. One system is better than
> > two. And we need to secure all of it anyway, as Salsa is a component
> > of the solution anyway.
>
> I read the analysis more that two systems is better than one thousand
> systems.
>
> I.e. centralizing (compared to building done on developers' systems) to a
> system that can be analyzed (which Gitlab is quite a challenge to do).
"centralize the risk as much as possible" applies to both cases, as
does the justification for it. And again, Salsa is already part of the
solution, so this argument doesn't seem very strong to me.
Having a bespoke system that nobody else uses has disadvantages too.
Yes you can minimize it and tailor it to the exact use case (as it is
today, and then you'll need to forever chase the trend of software
dev, as we have seen with Alioth). No security researcher is going to
spend any time doing audits of such a system (unless we pay them to),
but there's plenty of work done analyzing Gitlab. This concept that
everything needs to be internally auditable is very weird to me for an
open source project (I expect to see it and I do see it for internal
proprietary components in entreprises), presumably any such system
will run on a Linux kernel, but we are not asking maintainers of these
systems to personally audit the entire kernel (and libc and compiler
and and and), because they are widely used components that get enough
scrutiny externally w.r.t. the project. That's a good thing. By
reusing widely available and widely used open source components we can
share the burden of security audits, maintenance, development, etc.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 12:52, Ian Jackson
wrote:
>
> Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > As far as I can tell, from what was shared in these documents, the
> > security feature needed is an append-only repository, with safeguards
> > that an individual developer cannot bypass. As far as I can tell, the
> > same setup can be achieved with repository ACLs, and it would have the
> > same vulnerability: an admin with full access to the server can bypass
> > such measures, in either case. Is there something else I am missing?
>
> There is also an assurance question. Salsa is running gitlab, which
> is an extremely complicated piece of software with very many features.
> Any one of those features (which are constantly changing) offers an
> opportunity for compromise of Salsa. Also, we don't have the
> resources to audit all the code comeing from gitlab upstream.
>
> The attack surface of the dgit repos server is much smaller. Its
> supply chain integrity is much better. So it is much less likely to
> be compromised. (Also, diversity of implementation is helpful.)
Given we had a very well done and professional security review (thanks
Russ!), I think we should defer to that and take it into serious
consideration, and its conclusion seems quite clear to me in this
regard:
"My security recommendation in this case is therefore to centralize
the risk as much as possible, moving it off of individual uploader
systems with unknown security profiles and onto a central system that
can be analyzed and iteratively improved."
So I don't think this is a good argument. One system is better than
two. And we need to secure all of it anyway, as Salsa is a component
of the solution anyway.
> And, while I find gitlab and Salsa very convenient, we have already
> had one git forge fall by the wayside. As I say, the dgit repos
> server has already survived the death of one forge and it needs to
> survive any problem with Salsa.
The proposed solution already integrates with Salsa, so this point
seems moot to me. If we ever move off Gitlab, this would move too.
> Finally, using Salsa instead would involve modelling the Debian upload
> permissions model in repository ACLs, which we don't currently do.
> We would need to link uploaders' PGP keys to their ssh keys and rely
> on ssh keys, I think.
Why is that needed? From reading the document here:
https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt#L14
it seems to me developers would not be allowed at all to push directly
to this namespace, but only the tag2upload service would be allowed
(developers push to their normal repo, as they do today) by the ACLs,
and deleting tags/force pushing/deleting branches/etc would be
disallowed on top of that.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 12:10, Ian Jackson
wrote:
>
> Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote:
> > > Does it support gitweb? I thought it only supported regular Git
> > > operations, but I could be mistaken.
> >
> > I might be wrong, but this is what this looks like to me (it was
> > linked to me on IRC yesterday, wasn't aware of it before):
> >
> > https://browse.dgit.debian.org/
>
> Thanks for taking an interest.
>
> That is indeed a cgit view of the dgit git server.
>
> > The git repositories, sure. The git forge?
>
> I'm not sure what you mean by "forge". I think "forge" means
> "something like gitlab / sourcehut / github / ...". Ie, a system
> which doesn't just do git repository hosting, but also has (some or
> all of) a linked issue tracker, merge request review systme,
> discussion tooling, CI, etc.
>
> The t2u/dgit git server doesn't have any of those things. It's purely
> a git server, with some bespoke access control. So I don't think it's
> a "forge".
>
> It *does* present the contents of its repositories via a web interface
> for use by a web browser, but that view is completely read-only.
> (Indeed in the current setup in Debian it's served from a mirror.)
This is largely in the eye of the beholder as there's no strict
definition that I am aware of, so one could or could not include
these, but I do note that what you describe above is not really that
different from Alioth - that also didn't have merge requests or CIs,
and we didn't really use the rudimentary ticket system (IIRC it did
have one? Might be wrong). If Alioth was a forge, and I think it was,
then this alternative system also sounds like a forge to me.
One might have a different definition that results in different
subsets being included, but to me a forge is fundamentally a remote
git server hosting multiple repositories, where multiple people push
to.
> Whatever the definition of "forge" the key point you are making is
> that you see it as competing with Salsa. But, I don't think it does
> compete with Salsa. It doesn't offer any of the useful features that
> Salsa has.
>
> (In another sense, the Debian archive + ci.debian.net + the BTS +
> britney etc. etc., *is* competing with Salsa. In this view of things,
> browse.dgit.d.o is a view of part of the archive. But I don't think
> that's where you're coming from.)
Well, yes that is where I am coming from, as that's one of the
arguments being made by those opposed to Salsa. My understanding of
that position is the fact that it doesn't offer features is a _plus_,
not a minus.
> Salsa is not really suitable for use as the t2u/dgit repos git server,
> for the reasons others have explained in this thread. Very early in
> dgit's history, the dgit repos were hosted on Alioth, but we replaced
> that with a dedicated server for many reasons, some of which are
> security-related and discussed in Russ's review.
As far as I can tell, from what was shared in these documents, the
security feature needed is an append-only repository, with safeguards
that an individual developer cannot bypass. As far as I can tell, the
same setup can be achieved with repository ACLs, and it would have the
same vulnerability: an admin with full access to the server can bypass
such measures, in either case. Is there something else I am missing?
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 12:03, Jonas Smedegaard wrote: > > Quoting Luca Boccassi (2024-06-12 12:28:21) > > On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard wrote: > > > > > > Quoting Luca Boccassi (2024-06-12 10:21:40) > > > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote: > > > > > > > > > > Luca Boccassi writes: > > > > > > > > > > > And on the implementation details, I really do not like the idea of > > > > > > having a competing git forge with Salsa. This dgit server seems to > > > > > > just > > > > > > be a ye olde git-web interface. > > > > > > > > > > Does it support gitweb? I thought it only supported regular Git > > > > > operations, but I could be mistaken. > > > > > > > > I might be wrong, but this is what this looks like to me (it was > > > > linked to me on IRC yesterday, wasn't aware of it before): > > > > > > > > https://browse.dgit.debian.org/ > > > > > > > > > > If this goes forward, in my opinion it should exclusively use Salsa > > > > > > as the git server, to avoid duplicating infrastructure. > > > > > > > > > > I think you want the Git archive to be entirely separate from Salsa > > > > > so that it's a reliable source of tracing information. You don't > > > > > want to support force pushes, for example; the whole point is that it > > > > > should be append-only, which would be a controversial choice for > > > > > Salsa but which is fine for the archives of the uploaded packages. I > > > > > would also want a much smaller attack surface for that type of record > > > > > than than GitLab. GitLab is designed as a place to do interactive > > > > > work, not to keep a reliable permanent record. > > > > > > > > The git repositories, sure. The git forge? I don't see why. You can > > > > have these repositories in a separate namespace, which sets strong > > > > branch and tag protection rules to achieve what you describe. As far > > > > as I am aware, this is possible to do in Salsa already, it doesn't > > > > have to be a per-forge rule, it can be per-namespace, I think this is > > > > possible to achieve in Gitlab. I have not used tag protection rules > > > > (on gitlab, I used them on github though), but I do regularly use > > > > branch protection rules on my Salsa repositories. > > > > > > > > To be clear, I am exclusively talking about the git forge, as in > > > > salsa.debian.org, not the git repositories as they might exist on > > > > Salsa under the debian/ namespace or any other namespace. > > > > > > > > Having a separate namespace with strong ACLs seems exactly what you > > > > want, even if it duplicates the individual repositories (the backend > > > > git store deduplicates it anyway, so in practice it should be quite > > > > cheap). Having an entire separate git forge that competes with Salsa > > > > seems orthogonal to this, and counterproductive for the project. > > > > > > I fail to recognize how strong ACLs achieves exactly the same separate > > > storage on a separate host. Especially when the purpose is to minimize > > > attack vectors. > > > > As per the security review just shared, admin access to Salsa allows > > to push commits anyway which would get uploaded just the same, and > > again as per security review, this case benefits from centralizing: > > one host to maintain, and one set of admins to trust, is better than > > two. Especially as Salsa is Gitlab, which is maintained upstream and > > benefits from the many-eyes-and-many-users situation, while a > > completely custom local git forge reimplementation, other than > > inevitably suffering from bitrot at some point in the future, like all > > custom infrastructure, will have the disadvantage that nobody else > > uses it. This is the reason Alioth is gone, and it's a very good > > reason. > > So your argument is that that strong ACLs achieve exactly the same as > separate storage on a separate host, because separate storage on a > separate host inevitably leads to bitrot and lack of eyeballs. > > I rest my case. No, my argument is that append-only can (as far as I can tell) be achieved on Salsa too, it doesn't seem to necessitate a bespoke forge. The centralizing argument i
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard wrote: > > Quoting Luca Boccassi (2024-06-12 10:21:40) > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote: > > > > > > Luca Boccassi writes: > > > > > > > And on the implementation details, I really do not like the idea of > > > > having a competing git forge with Salsa. This dgit server seems to just > > > > be a ye olde git-web interface. > > > > > > Does it support gitweb? I thought it only supported regular Git > > > operations, but I could be mistaken. > > > > I might be wrong, but this is what this looks like to me (it was > > linked to me on IRC yesterday, wasn't aware of it before): > > > > https://browse.dgit.debian.org/ > > > > > > If this goes forward, in my opinion it should exclusively use Salsa > > > > as the git server, to avoid duplicating infrastructure. > > > > > > I think you want the Git archive to be entirely separate from Salsa > > > so that it's a reliable source of tracing information. You don't > > > want to support force pushes, for example; the whole point is that it > > > should be append-only, which would be a controversial choice for > > > Salsa but which is fine for the archives of the uploaded packages. I > > > would also want a much smaller attack surface for that type of record > > > than than GitLab. GitLab is designed as a place to do interactive > > > work, not to keep a reliable permanent record. > > > > The git repositories, sure. The git forge? I don't see why. You can > > have these repositories in a separate namespace, which sets strong > > branch and tag protection rules to achieve what you describe. As far > > as I am aware, this is possible to do in Salsa already, it doesn't > > have to be a per-forge rule, it can be per-namespace, I think this is > > possible to achieve in Gitlab. I have not used tag protection rules > > (on gitlab, I used them on github though), but I do regularly use > > branch protection rules on my Salsa repositories. > > > > To be clear, I am exclusively talking about the git forge, as in > > salsa.debian.org, not the git repositories as they might exist on > > Salsa under the debian/ namespace or any other namespace. > > > > Having a separate namespace with strong ACLs seems exactly what you > > want, even if it duplicates the individual repositories (the backend > > git store deduplicates it anyway, so in practice it should be quite > > cheap). Having an entire separate git forge that competes with Salsa > > seems orthogonal to this, and counterproductive for the project. > > I fail to recognize how strong ACLs achieves exactly the same separate > storage on a separate host. Especially when the purpose is to minimize > attack vectors. As per the security review just shared, admin access to Salsa allows to push commits anyway which would get uploaded just the same, and again as per security review, this case benefits from centralizing: one host to maintain, and one set of admins to trust, is better than two. Especially as Salsa is Gitlab, which is maintained upstream and benefits from the many-eyes-and-many-users situation, while a completely custom local git forge reimplementation, other than inevitably suffering from bitrot at some point in the future, like all custom infrastructure, will have the disadvantage that nobody else uses it. This is the reason Alioth is gone, and it's a very good reason. > > > That Git archive is not parallel to or competitive with Salsa and doesn't > > > provide most of the functionality that Salsa does. It has a different > > > purpose. > > > > I disagree strongly. As we have seen in the recent Salsa thread on > > d-private, there are a few but very strongly opinionated people who > > are vehemently against Salsa and would like to see it gone. Having a > > parallel and competing git forge I fear would give them very strong > > ammunition to do so: "if the real uploads and the real repositories > > are on a separate and independent git forge, why have Salsa at all? > > Get rid of it and use the other forge exclusively." > > I don't follow d-private, but sounds to me like that argument goes both > ways - i.e. also "if the real uploads and the real repositories are on > (some specially locked down section of) same git forge, why not embrace > additional features offered from same vendor of said forge?" I don't follow, we already use features from Salsa? Like the CI pipeline, which is awesome. ACLs on repositories are not really unique or particular to Github, modern forges pretty much have to support them, Github has them too.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 10:14, Helmut Grohne wrote: > > On Wed, Jun 12, 2024 at 06:50:44AM +0200, Ansgar 🙀 wrote: > > In addition it reintroduces trust in weak cryptographic hashes which > > effort was spent to remove. > > Thanks for reminding. While I've seen arguments in favour of the > weaknesses of sha1 not affecting our use much, the xz-incident changes > the weights of those arguments for me. I am now wondering whether we can > be more proactive about changing the hash function used by git. For new > repositories, this seems as simple as git init --object-format=sha256. > Doing so will make repositories inaccessible to people running buster or > older and I guess we can live with that limitation. It is not clear to > me how repositories are converted. To me it seems plausible to deny use > of sha1 hashes with debpush at this time (even though that is not > implemented right now). > > I note that use of weak hashes in the current tag2upload is not a > fundamental blocker but something that I expect proponents to work on in > case the GR passes. Would one of the proponents confirm that they see > this as worth spending their time on (on the condition that the GR > passes)? A side note, but related: recently I had the (dis)pleasure of having to deal with a git repository that was switched to sha256 (SUSE's Gitea instance). The conversion is destructive, and breaks, for example, git submodules functionality (a sha1 repository cannot use sha256 submodules). So I'd be very careful in assuming repositories can be converted later. It would seem to me to be much, much safer to do this from day one: wait for Gitlab to introduce sha256 (they are bound to, as there's really no choice), then add a tag2upload namespace that forces all repos under it to use sha256, and use it from the get-go. Converting later I am afraid would risk causing a huge amount of pain, from the experience dealing with this.
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote: > > Luca Boccassi writes: > > > And on the implementation details, I really do not like the idea of > > having a competing git forge with Salsa. This dgit server seems to just > > be a ye olde git-web interface. > > Does it support gitweb? I thought it only supported regular Git > operations, but I could be mistaken. I might be wrong, but this is what this looks like to me (it was linked to me on IRC yesterday, wasn't aware of it before): https://browse.dgit.debian.org/ > > If this goes forward, in my opinion it should exclusively use Salsa as > > the git server, to avoid duplicating infrastructure. > > I think you want the Git archive to be entirely separate from Salsa so > that it's a reliable source of tracing information. You don't want to > support force pushes, for example; the whole point is that it should be > append-only, which would be a controversial choice for Salsa but which is > fine for the archives of the uploaded packages. I would also want a much > smaller attack surface for that type of record than than GitLab. GitLab > is designed as a place to do interactive work, not to keep a reliable > permanent record. The git repositories, sure. The git forge? I don't see why. You can have these repositories in a separate namespace, which sets strong branch and tag protection rules to achieve what you describe. As far as I am aware, this is possible to do in Salsa already, it doesn't have to be a per-forge rule, it can be per-namespace, I think this is possible to achieve in Gitlab. I have not used tag protection rules (on gitlab, I used them on github though), but I do regularly use branch protection rules on my Salsa repositories. To be clear, I am exclusively talking about the git forge, as in salsa.debian.org, not the git repositories as they might exist on Salsa under the debian/ namespace or any other namespace. Having a separate namespace with strong ACLs seems exactly what you want, even if it duplicates the individual repositories (the backend git store deduplicates it anyway, so in practice it should be quite cheap). Having an entire separate git forge that competes with Salsa seems orthogonal to this, and counterproductive for the project. > That Git archive is not parallel to or competitive with Salsa and doesn't > provide most of the functionality that Salsa does. It has a different > purpose. I disagree strongly. As we have seen in the recent Salsa thread on d-private, there are a few but very strongly opinionated people who are vehemently against Salsa and would like to see it gone. Having a parallel and competing git forge I fear would give them very strong ammunition to do so: "if the real uploads and the real repositories are on a separate and independent git forge, why have Salsa at all? Get rid of it and use the other forge exclusively."
Re: [RFC] General Resolution to deploy tag2upload
On Tue, 11 Jun 2024 at 23:25, Sean Whitton wrote: > > Hello everyone, > > This is a draft GR. I'm posting it now for textual review, because of > the relative shortness of our official discussion periods. > > After some time for review, I'll post again seeking seconds. > > The first sections are an introductory discussion. For the actual GR > text, scroll down to the bottom of this e-mail. Thanks. > > = > INTRODUCTION > > The tag2upload system, designed for deployment on official Debian > infrastructure, allows DDs and DMs to make source-only uploads simply by > pushing a signed git tag. There are two key advantages: > > - it will be much quicker and easier for us to do most of our uploads > > - it improves the traceability and auditability of our source-only > uploads, in ways that are particular salient in the wake of xz-utils. > > The system works like this: > > 1. Maintainer types 'git debpush' to sign and push a suitable git tag. >The tag includes certain metadata that makes the maintainer's >intention to upload fully traceable, and unambiguous. > > 2. A robot on DSA infrastructure automatically, reliably and traceably >builds the source package, and uploads it to the Debian Archive. > > tag2upload will be an additional option for your source-only uploads; > no-one will be required to use it. For more information on the details > of the system itself, I've included some links down below. Hi, I like the idea of pushing a git tag to upload a lot, thanks for working on this! One comment on the linked document: https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt this just uses the term "dgit" without defining or linking to some documentation. I was not really familiar with it so I was a bit confused by it, I'd suggest maybe adding some clarification. And on the implementation details, I really do not like the idea of having a competing git forge with Salsa. This dgit server seems to just be a ye olde git-web interface. If this goes forward, in my opinion it should exclusively use Salsa as the git server, to avoid duplicating infrastructure. That way we have only one place to look at for all git repos. Kind regards, Luca Boccassi
Re: Question to all candidates: What are your technical goals
On Fri, 5 Apr 2024 at 11:18, Andreas Tille wrote: > > Am Thu, Apr 04, 2024 at 02:41:00PM +0100 schrieb Luca Boccassi: > > > Please don't get me wrong: I do not consider Fedora a commercial > > > entity. I simply subscribe the statement that we are facing some > > > problems in Debian since we are not a commercial entity. > > > > I think the framing is slightly misleading: it's true that a > > commercial entity with a hierarchical structure would not have the > > same issue, but the point I am making is that there's nothing stopping > > a non-commercial entity from having a structure that allows the same > > decision-making and executing, as proved by Fedora. > > Well, do you think well-respected members of our community who disagree > with a change of structure are "nothing"? In preparation of my platform > I started kind of a test ballon inside DPT where I spotted something I > considered wrong inside the team policy and suggested a change[1]. > There were a lot of positive responses and finally the change was > accepted. But even before this happened we've lost two major > contributors[2] (leaving more or less silently) and [3]. I confirm I > made mistakes in this process and hopefully learned from it. > > So we have to deal with people and changing a structure that has evolved > over >30 years might be harder than in the case of other distributions > with a different history. IMHO changing a structure is harder than > creating one from scratch. That is answered in the bit you quoted below: > _plus_ precise and explicit choices about project governance Project governance is a choice, there's no law of physics that says it has to be done one way or the other, even outside of a commercial setting. Yes, it is harder to change than to start from scratch, there's no doubt about it. > > Hence, it's not > > just the fact that Debian is not a commercial entity that leads to the > > status quo, but the combination of not being a commercial entity > > _plus_ precise and explicit choices about project governance. > > I'm kindly inviting everybody to join me in drafting a GR about this (no > matter whether I might get elected or not). Happy to help > > > If you compare this to Debian what exactly is your proposal to change > > > for the better? > > > > For starters there needs to be a decision on whether the status quo is > > fine or change is needed. That is non-obvious, I have my opinion but > > others will have theirs. It would mean the end of "my package is my > > fiefdom", and a move towards collective maintenance. > > I share this opinion 100%. > > > From the organizational point of view, it would require a GR to change > > in the constitution to enshrine the power to take technical decisions > > and make them happen into a constitutional body - the CTTE will > > probably say "no no no not us, please, no", but I'm pretty sure that's > > exactly where such power should reside, especially because they don't > > want it. > > I fail to see the logic in this "especially because they don't want it" > but I agree that I see the potential decision making body in the CTTE. > To say it clearly: It should by no means be DPL (and I hope your logic > does not apply to this statement as well. ;-P ) There's an old maxim about the people best suited to hold power being those who want it the least or not at all, it was a quip made in that general direction, no special meaning. > > A procedure to submit proposals for discussion with the whole > > project should be established (we already have the DEP process for > > example), that ends with a vote of the decision makers body. And once > > the body makes a technical strategy decision, them or whoever they > > want to empower, can go and make it happen, without having to walk on > > eggshells and dance around sacred cows - the time to dissent and > > discuss is _before_ the decision is made, not _after_. > > To stick to one example I gave in an other thread on this list: Assuming > we decided to move all packages on Salsa, I could start importing > packages that are not on Salsa and upload these starting from the day > after this decision without asking the maintainer? Being empowered to execute a decision doesn't discount common courtesy, so maintainers would be kept in the loop, but essentially yes, that would be one example > > In Fedora every > > proposal must include a criteria to allow declaring that the game's a > > bogey and plan to rollback, in case something goes wrong, but this is > > again decided by the decision makers body. > > Interesting detail which is probably not feasible for every decision > (since its hard to imagine how to roll back a "move all packages on > Salsa" decision). In that case it would probably be something along the lines of "it is no longer mandatory"
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 21:30, Salvo Tomaselli wrote: > > > In practical terms, it would probably be made easier if it was > > mandatory for all packages to be on Salsa, either in the 'debian' > > namespace or in a team namespace (but not under individual users). > > Realistically, even if you decide "everything is now team maintained", if > there is only 1 person who cares about a certain package there won't be any > team member doing anything about it. So having it on salsa or whatever won't > really do much, besides being annoying for people who have to change their > workflow for no reason. Sure, but this is in the context of project-wide changes discussed above. > Also let's not forget that it is expected for people who are not DD to > contribute to debian, and they can only create repositories on salsa under > their own name (for good reason, mostly). Such contributors need a DD sponsor, which means access can be granted to individual repositories.
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 13:40, Andreas Tille wrote: > > Hi Luca, > > Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > > > That's the price we currently pay for being not a commercial entity, > > > > > > I fully subscribe to this statement. > > > > I don't think commercial entities have anything to do with this. > > Fedora is not a commercial entity (please, no FUD about RH) and yet it > > can take decisions and implement them just fine. It's entirely a > > question of self-organization and what rules we decide for the > > project. > > Please don't get me wrong: I do not consider Fedora a commercial > entity. I simply subscribe the statement that we are facing some > problems in Debian since we are not a commercial entity. I think the framing is slightly misleading: it's true that a commercial entity with a hierarchical structure would not have the same issue, but the point I am making is that there's nothing stopping a non-commercial entity from having a structure that allows the same decision-making and executing, as proved by Fedora. Hence, it's not just the fact that Debian is not a commercial entity that leads to the status quo, but the combination of not being a commercial entity _plus_ precise and explicit choices about project governance. > > > I need to admit that I (currently) don't know much about Fedora (but I > > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > > took the chance to talk to OpenSUSE and Nix about organisatorical > > > solutions. There was no booth by Fedora I could show up. > > > > In short, Fedora project members elect a technical committee, FESCO. > > Project members can submit proposals to this committee for > > project-wide changes, which votes on whether to approve them or reject > > them. If they are approved, the committee and the proposer are > > empowered to enact the changes distro-wide - whether individual > > package maintainers like them or not. An approved proposal can fail > > and be rolled back for technical reasons (e.g.: unexpected issues crop > > up at implementation time), but not because random package maintainers > > practice obstructionism because they don't like the decision. > > If you compare this to Debian what exactly is your proposal to change > for the better? For starters there needs to be a decision on whether the status quo is fine or change is needed. That is non-obvious, I have my opinion but others will have theirs. It would mean the end of "my package is my fiefdom", and a move towards collective maintenance. >From the organizational point of view, it would require a GR to change in the constitution to enshrine the power to take technical decisions and make them happen into a constitutional body - the CTTE will probably say "no no no not us, please, no", but I'm pretty sure that's exactly where such power should reside, especially because they don't want it. A procedure to submit proposals for discussion with the whole project should be established (we already have the DEP process for example), that ends with a vote of the decision makers body. And once the body makes a technical strategy decision, them or whoever they want to empower, can go and make it happen, without having to walk on eggshells and dance around sacred cows - the time to dissent and discuss is _before_ the decision is made, not _after_. In Fedora every proposal must include a criteria to allow declaring that the game's a bogey and plan to rollback, in case something goes wrong, but this is again decided by the decision makers body. In practical terms, it would probably be made easier if it was mandatory for all packages to be on Salsa, either in the 'debian' namespace or in a team namespace (but not under individual users). Then perhaps for each approved decision, until the project is completed the implementer(s) would automatically get write access to all teams namespaces to push the changes - as MRs because reviews are good, but with the powers to merge them too. I'm getting ahead of myself, but hopefully you get the idea.
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 11:39, Andreas Tille wrote: > > Hi Marc, > > Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber: > > On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote: > > "we now use Wayland > > instead of X11", "please don't create your system users with adduser and > > more, use a declarative approach". > > > > At the moment, we simply dont take such decisions. I think that's a > > problem. > > I think I get your point now. Thanks for these examples. You might > have a point in these specific ones but I see Debian leading in other > aspects. > > As far as I know other major distributions do not undertake the time_t > 64bit transition (whether this marks leadership or not is questionable > but it will make us the leading distribution on those architectures in > future). Of course they are, most of the important work lately has been done by SUSE for example, to replace legacy components that will hopelessly break in 2038. Of course they have an advantage in not having to carry around dead architectures, so it's easier. > I'm not well informed about other distributions but seeked the internet > and for instance found some article about reproducible builds from > 2019[2] where Debian and ArchLinux are mentioned frequently but Fedora > is not. I've picked that older article since taking the lead means who > started that effort and I think we are in this game. > > Apropos ArchLinux: I would love if Debian would manage to craft such a > great documentation in Wiki. That's not a "technological" lead but > we've lost the lead in documentation by far which is in my perception a > weaker point than the time we adopt one or the other technical change. > > I think we are doing a good job regarding CI with adding autopkgtests > (but we could do even better for sure). I'm not informed about the > status of CI in other distributions and whether there exists something > like Salsa CI. I'm positively convinced that Debian has reached a level > of complexity which makes CI tests mandatory for every important package > and I would love if we could do the lead here. OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's source control system has a CI integrated with it that is similar to the one we have. Packit is even starting to make its way in upstream projects's CIs, we use it in systemd for example, so that upstream PRs also build and test Fedora packages in Fedora images. We do the same with Debian and autopkgtest btw. > > > > Are our technical > > > > decision-making processes up to today's challenges? > > > > > > Would you mind clarifying this question? We have the CTTE as > > > decision-making instance but I'm not sure whether you are refering to > > > this. > > > > The CTTE is a tie-breaker which is only invoked to resolve a fight. And > > if invoked, the decision takes months. In other sitations, we keep > > fighting in the open, probably doing a GR, which makes the news even > > before we have decided anything. > > > > That's the price we currently pay for being not a commercial entity, > > I fully subscribe to this statement. I don't think commercial entities have anything to do with this. Fedora is not a commercial entity (please, no FUD about RH) and yet it can take decisions and implement them just fine. It's entirely a question of self-organization and what rules we decide for the project. > > so > > that we don't have a project leader who has the power to say "we're > > going to do X", like the board or the managing director of a commercial > > company has. > > I consider the DPL as a "Leader with no power". Convincing a huge > number of volunteers to pull a string into the same direction is a way > harder job than telling employees of a company what to do next. I'm > aware of this challenge. > > > Seriously, I don't how Fedora takes their technical > > decision, but there has to be a reason why they're so far ahead of us > > technologically. > > I need to admit that I (currently) don't know much about Fedora (but I > hope I could fix this in the near future). At Chemnitzer Linuxtage I > took the chance to talk to OpenSUSE and Nix about organisatorical > solutions. There was no booth by Fedora I could show up. In short, Fedora project members elect a technical committee, FESCO. Project members can submit proposals to this committee for project-wide changes, which votes on whether to approve them or reject them. If they are approved, the committee and the proposer are empowered to enact the changes distro-wide - whether individual package maintainers like them or not. An approved proposal can fail and be rolled back for technical reasons (e.g.: unexpected issues crop up at implementation time), but not because random package maintainers practice obstructionism because they don't like the decision.
Re: recent changes to the CRA address FLOSS community concerns?
On Sat, 30 Dec 2023 at 20:25, Florian Weimer wrote: > > * Paul Wise: > > > Does anyone have any more info about the changes? > > Isn't that the crux of the matter? > > It appears that everyone in the EU political process is withholding > details, like the concrete text as it exists today. Selective leaks > are likely manipulative to some extent, perhaps trying to undermine > the credibility of the legislative process itself, without actually > caring much about FOSS. > > An objective analysis would need the complete consolidated text, > including translations. The German version tends to be clearer what > commercial activity is supposed to mean, for example. The latest revision was published 10 days ago: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CONSIL:ST_17000_2023_INIT
Re: CRA and PLD vote status
On Fri, 8 Dec 2023 at 23:04, Bart Martens wrote: > > On Fri, Dec 08, 2023 at 10:06:45PM +0100, Lucas Nussbaum wrote: > > Hi, > > > > On 08/12/23 at 21:58 +0100, Kurt Roeckx wrote: > > > [ ] Choice 1: CRA and PLD proposals include regulations detrimental to > > > FOSS > > > [ ] Choice 2: The EU should clarify that non-commercial FOSS is exempted > > > > "non-commercial FOSS" sounds like CC BY-NC-SA (which is not FOSS). What > > this option is trying to say is that FOSS development outside commercial > > context should be exempted (or non-commercial FOSS organizations). > > > > However I cannot find a wording that fits on a single line... > > Maybe this? > [ ] Choice 2: The EU should exempt non-commercial use of FOSS" It's not just use, development too. Maybe: "CRA and PLD proposals should only apply to commercial ventures"
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Wed, 22 Nov 2023 at 20:35, Bart Martens wrote: > > On Wed, Nov 22, 2023 at 06:46:06PM +, Luca Boccassi wrote: > > On Wed, 22 Nov 2023 at 09:28, Bart Martens wrote: > > > > > > On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote: > > > > I feel like we're getting trapped by big corp and their lobbying > > > > power, and we need to use stronger words. > > > > > > Probably in a different way. I'd rather prefer Debian to defend the DFSG, > > > including DFSG 6. If the EU were to draw a line for compulsory liability, > > > then > > > it should not be between commercial and nonprofit, but rather between > > > FOSS and > > > non-FOSS. For example, in my opinion "awscli" is FOSS, and the usual > > > liability > > > disclaimer in FOSS licenses should also be valid for "awscli". This is, > > > in my > > > understanding, a different opinion than discussed so far, right? > > > > That would not be a good outcome. Just because a smartphone ships open > > source software, it doesn't mean its vendor should get away with not > > providing security updates after a few months, causing the phone > > owners to lose their data or worse. > > That is a different case. The user of a smartphone depends on the vendor for > keeping the smarthpone safe for use during a reasonable time after purchase. > I follow you on that. It's not really different, if you can get out of security maintenance of some software just because of its license, then it affects any product using software. That would be quite an obvious loophole to take advantage of, and that's probably why the distinction in these regulations is never on the license, but on whether it's a commercial activity or not.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Wed, 22 Nov 2023 at 09:28, Bart Martens wrote: > > On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote: > > I feel like we're getting trapped by big corp and their lobbying > > power, and we need to use stronger words. > > Probably in a different way. I'd rather prefer Debian to defend the DFSG, > including DFSG 6. If the EU were to draw a line for compulsory liability, then > it should not be between commercial and nonprofit, but rather between FOSS and > non-FOSS. For example, in my opinion "awscli" is FOSS, and the usual liability > disclaimer in FOSS licenses should also be valid for "awscli". This is, in my > understanding, a different opinion than discussed so far, right? That would not be a good outcome. Just because a smartphone ships open source software, it doesn't mean its vendor should get away with not providing security updates after a few months, causing the phone owners to lose their data or worse.
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 2023-11-19 at 23:21 +, Luca Boccassi wrote: > Second version, taking into account feedback. Looking for seconds at > this point: Elbrus spotted a typo, fixed below - that's the only change, "taking taking" -> "taking" in the second paragraph - GENERAL RESOLUTION STARTS - Debian Public Statement about the EU Cyber Resilience Act and the Product Liability Directive The European Union is currently preparing a regulation "on horizontal cybersecurity requirements for products with digital elements" known as the Cyber Resilience Act (CRA). It's currently in the final "trilogue" phase of the legislative process. The act includes a set of essential cybersecurity and vulnerability handling requirements for manufacturers. It will require products to be accompanied by information and instructions to the user. Manufacturers will need to perform risk assessments and produce technical documentation and for critical components, have third-party audits conducted. Security issues under active exploitation will have to be reported to European authorities within 24 hours (1). The CRA will be followed up by an update to the existing Product Liability Directive (PLD) which, among other things, will introduce the requirement for products on the market using software to be able to receive updates to address security vulnerabilities. Given the current state of the electronics and computing devices market, constellated with too many irresponsible vendors not taking enough precautions to ensure and maintain the security of their products, resulting in grave issues such as the plague of ransomware (that, among other things, has often caused public services to be severely hampered or shut down entirely, across the European Union and beyond, to the detriment of its citizens), the Debian project welcomes this initiative and supports its spirit and intent. The Debian project believes Free and Open Source Software Projects to be very well positioned to respond to modern challenges around security and accountability that these regulations aim to improve for products commercialized on the Single Market. Debian is well known for its security track record through practices of responsible disclosure and coordination with upstream developers and other Free and Open Source Software projects. The project aims to live up to the commitment made in the Debian Social Contract: "We will not hide problems." (2) The Debian project welcomes the attempt of the legislators to ensure that the development of Free and Open Source Software is not negatively affected by these regulations, as clearly expressed by the European Commission in response to stakeholders' requests (1) and as stated in Recital 10 of the preamble to the CRA: 'In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation.' The Debian project however notes that not enough emphasis has been employed in all parts of these regulations to clearly exonerate Free and Open Source Software developers and maintainers from being subject to the same liabilities as commercial vendors, which has caused uncertainty and worry among such stakeholders. Therefore, the Debian project asks the legislators to enhance the text of these regulations to clarify beyond any reasonable doubt that Free and Open Source Software developers and contributors are not going to be treated as commercial vendors in the exercise of their duties when merely developing and publishing Free and Open Source Software, with special emphasis on clarifying grey areas, such as donations, contributions from commercial companies and developing Free and Open Source Software that may be later commercialised by a commercial vendor. It is fundamental for the interests of the European Union itself that Free and Open Source Software development can continue to thrive and produce high quality software components, applications and operating systems, and this can only happen if Free and Open Source Software developers and contributors can continue to work on these projects as they have been doing before these new regulations, especially but not exclusively in the context of nonprofit organizations, without being encumbered by legal requirements that are only appropriate for commercial companies and enterprises. == Sources: (1) CRA proposals and links: https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cyber
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Tue, 21 Nov 2023 at 16:46, Salvo Tomaselli wrote: > > In data martedì 21 novembre 2023 16:13:32 CET, Luca Boccassi ha scritto: > > > Microsoft was not happy with having to unbundle Bing and Edge from > > Windows. > > It is still impossible to uninstall edge... https://arstechnica.com/gadgets/2023/11/europeans-can-soon-strip-bing-edge-other-microsoft-cruft-from-windows-11/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Tue, 21 Nov 2023 at 08:14, Thomas Goirand wrote: > > On 11/20/23 00:21, Luca Boccassi wrote: > > Second version, taking into account feedback. Looking for seconds at > > this point: > > > > - GENERAL RESOLUTION STARTS - > > > > Debian Public Statement about the EU Cyber Resilience Act and the > > Product Liability Directive > > > > The European Union is currently preparing a regulation "on horizontal > > cybersecurity requirements for products with digital elements" known as > > the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > > phase of the legislative process. The act includes a set of essential > > cybersecurity and vulnerability handling requirements for > > manufacturers. > > It will require products to be accompanied by information and > > instructions to the user. Manufacturers will need to perform risk > > assessments and produce technical documentation and for critical > > components, have third-party audits conducted. Security issues under > > active exploitation will have to be reported to European authorities > > within 24 hours (1). The CRA will be followed up by an update to the > > existing Product Liability Directive (PLD) which, among other things, > > will introduce the requirement for products on the market using > > software > > to be able to receive updates to address security vulnerabilities. > > > > Given the current state of the electronics and computing devices > > market, > > constellated with too many irresponsible vendors not taking taking > > enough precautions to ensure and maintain the security of their > > products, > > resulting in grave issues such as the plague of ransomware (that, among > > other things, has often caused public services to be severely hampered > > or > > shut down entirely, across the European Union and beyond, to the > > detriment of its citizens), the Debian project welcomes this initiative > > and supports its spirit and intent. > > > > The Debian project believes Free and Open Source Software Projects to > > be > > very well positioned to respond to modern challenges around security > > and > > accountability that these regulations aim to improve for products > > commercialized on the Single Market. Debian is well known for its > > security track record through practices of responsible disclosure and > > coordination with upstream developers and other Free and Open Source > > Software projects. The project aims to live up to the commitment made > > in > > the Debian Social Contract: "We will not hide problems." (2) > > > > The Debian project welcomes the attempt of the legislators to ensure > > that the development of Free and Open Source Software is not negatively > > affected by these regulations, as clearly expressed by the European > > Commission in response to stakeholders' requests (1) and as stated in > > Recital 10 of the preamble to the CRA: > > > > 'In order not to hamper innovation or research, free and open-source > >software developed or supplied outside the course of a commercial > >activity should not be covered by this Regulation.' > > > > The Debian project however notes that not enough emphasis has been > > employed in all parts of these regulations to clearly exonerate Free > > and Open Source Software developers and maintainers from being subject > > to the same liabilities as commercial vendors, which has caused > > uncertainty and worry among such stakeholders. > > > > Therefore, the Debian project asks the legislators to enhance the > > text of these regulations to clarify beyond any reasonable doubt that > > Free and Open Source Software developers and contributors are not going > > to be treated as commercial vendors in the exercise of their duties > > when > > merely developing and publishing Free and Open Source Software, with > > special emphasis on clarifying grey areas, such as donations, > > contributions from commercial companies and developing Free and Open > > Source Software that may be later commercialised by a commercial > > vendor. > > It is fundamental for the interests of the European Union itself that > > Free and Open Source Software development can continue to thrive a
Re: Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
> > Second version, taking into account feedback. Looking for seconds > at > > this point: > > Maybe Santiago wants to adopt this text, rather than having 2 > options? Already attempted that last week: https://lists.debian.org/debian-vote/2023/11/msg00051.html Unfortunately time available is limited by the GR process. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Re: General Resolution: Statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
> "the EU aims to cripple": this is a strong statement that will annoy > all > readers who believe that the EU aims to make a better world and > possibly > reduce the support for and impact of the GR. Maybe "If accepted as > it > is, CRA will cripple" There are many such problems with the proposed text. An alternative text that aims to solve them is currently looking for seconds: https://lists.debian.org/debian-vote/2023/11/msg00065.html -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 19 Nov 2023 at 00:21, Sam Hartman wrote: > > > "Bart" == Bart Martens writes: > >> > >> * A commercial company writes free-software that for all > >> practical purposes can be used only for access to their > >> proprietary web service. I'd rather not allow arguments about > >> whether a flaw is on the web service side or the client API side > >> to be used to help the company get out of liability to their > >> customers/users. > > Bart> I guess "awscli" is an example of this situation. > > Sure, let's say it is. > One could quibble about whether there are alternate implementations of > AWS's API, but for most uses, I'd agree with awscli being an example of > what I'm talking about. > > Bart> https://packages.debian.org/sid/awscli > Bart> > https://metadata.ftp-master.debian.org/changelogs//main/a/awscli/awscli_2.12.0-1_copyright > Bart> So the EU would hold Amazon liable for damages caused by using > Bart> "awscli", overruling the "without warranties" clause in the > Bart> license. Well, then next time Amazon might choose to only > Bart> provide documentation of the API, without publishing an open > Bart> source example implementation like "awscli". That's a loss for > Bart> foss. It illustrates the value of DFSG 6. > > Ah, because the regulations specifically exclude SAAS and so Amazon > doesn't have liability for the API unless they publish software to use > the API? > > If that's your point, I certainly understand you better. > > If in practice we end up with less open-source software because of > things like that, I agree it would be a negative. The software license makes no difference, if there's a commercial activity involved then the vendor is responsible to its customers. Amazon didn't build awscli because it's a hobby activity or as a favor to the open source ecosystem, they built it because their cloud customers demand it and use it (same for Microsoft for azcli, and for Google for the gcloud cli). So it would not make any difference one way or the other, these softwares will still exist, and will still be open source because there's nothing to gain from doing otherwise. It's a good thing that cloud vendors are held accountable for the security of the software they ship on users' machines, even if their services fall under different regulatory regimes. A certain vendor that I won't name regularly bundles an outdated set of python interpreter, standard library, ancillary modules _and_ OpenSSL as cherry on top with their CLI tool - maybe once these regulations are in place, they'll finally get their act together and start doing proper security maintenance of said product.
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
uropean Commission to a question from the European Parliament on FOSS awareness: https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html (2) Debian Social Contract No. 2, 3 and 4 https://www.debian.org/social_contract - GENERAL RESOLUTION ENDS - -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Wed, 15 Nov 2023 at 13:53, Lucas Nussbaum wrote: > > On 15/11/23 at 11:38 +, Luca Boccassi wrote: > > On Wed, 15 Nov 2023 at 06:23, Lucas Nussbaum wrote: > > > > > > On 15/11/23 at 00:49 +, Luca Boccassi wrote: > > > > What do you think? Here's what I came up with: > > > > > > Hi, > > > > > > FWIW, I would likely second something along those lines. Some comments: > > > > > > > The Debian project however notes that not enough emphasis has been > > > > employed in all parts of these regulations to clearly exonerate Free > > > > and Open Source Software Projects from being subject to the same > > > > liabilities as commercial products > > > > > > I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells > > > services around a free software product, I think it's OK if they are > > > covered by this regulation. Maybe it would be better with > > > s/Projects/Organizations/? > > > > > > Maybe we should underline specific borderline situations where the > > > impact of the regulation would be unclear? > > > > I think the two paragraphs are clearer than that already when taken > > together, especially the last bit which essentially boils down to "let > > us continue to do what we are doing and go after vendors instead > > kkthxbye", but what about this rewording: > > > > The Debian project however notes that not enough emphasis has been > > employed in all parts of these regulations to clearly exonerate Free > > and Open Source Software developers and maintainers from being subject > > to the same liabilities as commercial vendors, which has caused > > uncertainty and worry among such stakeholders. > > > > Therefore, the Debian project asks the legislators to enhance the > > text of these regulations to clarify beyond any reasonable doubt that > > Free and Open Source Software developers and contributors are not going > > to be treated as commercial vendors in the exercise of their duties when > > merely developing and publishing Free and Open Source Software, with > > special emphasis on clarifying grey areas, such as donations, > > contributions from commercial companies and developing Free and Open > > Source Software that may be later commercialised by a > > commercial vendor. It is fundamental for the interests of the > > European Union itself that Free and Open Source Software development > > can continue to thrive and produce high quality software components, > > applications and operating systems, and this can only happen if Free > > and Open Source Software developers and contributors can continue to > > work on these projects as they have been doing before these new > > regulations, without being encumbered by legal requirements that are > > only appropriate for commercial companies and enterprises. > > This looks better, thanks! > > I wonder if we should have something like "Free software development by > nonprofit organizations" somewhere. I agree that are many situations > where development happens outside of the context of an NPO, and where > this regulation should not apply. But it might be easier for Debian to > focus on its own context. How about: ...if Free and Open Source Software developers and contributors can continue to work on these projects as they have been doing before these new regulations, especially but not exclusively in the context of nonprofit organizations, without being encumbered by legal requirements that are only appropriate for commercial companies and enterprises.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Wed, 15 Nov 2023 at 12:59, Santiago Ruano Rincón wrote: > > El 15/11/23 a las 00:49, Luca Boccassi escribió: > > On Sun, 2023-11-12 at 12:10 -0300, Santiago Ruano Rincón wrote: > > > Dear Debian Fellows, > > > > > > Following the email sent by Ilu to debian-project (Message-ID: > > > <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have > > > discussed during the MiniDebConf UY 2023 with other Debian Members, I > > > would like to call for a vote about issuing a Debian public statement > > > regarding > > > the EU Cyber Resilience Act (CRA) and the Product Liability Directive > > > (PLD). The CRA is in the final stage in the legislative process in the > > > EU Parliament, and we think it will impact negatively the Debian > > > Project, users, developers, companies that rely on Debian, and the FLOSS > > > community as a whole. Even if the CRA will be probably adopted before > > > the time the vote ends (if it takes place), we think it is important to > > > take a public stand about it. > > > > Hi Santiago, > > Hello Luca > > > > > It seems clear that there is a lot of interest in the project to > > express a position on this matter. But as mentioned in the thread by > > myself and others, I find some of the specifics of the text a bit > > problematic - and some of the responses it elicited even more so. > > > > So, I'd like to propose an alternative text, that uses a very similar > > preamble and still expresses a strong request to the legislators to > > protect the interests of FOSS and its contributors and clarify any > > issue, grey area or confusion that might be present in the current > > texts, and put it beyond any reasonable doubt that FOSS projects can > > continue working as they have, while at the same time supporting the > > spirit of the law and its goal to improve the abysmal landscape of > > software security in commercial products. > > > > What do you think? Here's what I came up with: > > > > - GENERAL RESOLUTION STARTS - > > > > Debian Public Statement about the EU Cyber Resilience Act and the > > Product Liability Directive > > > > The European Union is currently preparing a regulation "on horizontal > > cybersecurity requirements for products with digital elements" known as > > the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > > phase of the legislative process. The act includes a set of essential > > cybersecurity and vulnerability handling requirements for manufacturers. > > It will require products to be accompanied by information and > > instructions to the user. Manufacturers will need to perform risk > > assessments and produce technical documentation and for critical > > components, have third-party audits conducted. Security issues under > > active exploitation will have to be reported to European authorities > > within 24 hours (1). The CRA will be followed up by an update to the > > existing Product Liability Directive (PLD) which, among other things, > > will introduce the requirement for products on the market using software > > to be able to receive updates to address security vulnerabilities. > > > > Given the current state of the electronics and computing devices market, > > constellated with too many irresponsible vendors (largely employing > > proprietary software) not taking taking enough precautions to ensure and > > maintain the security of their products, resulting in grave issues such > > as the plague of ransomware (that, among other things, has often caused > > public services to be severely hampered or shut down entirely, across > > the European Union and beyond, to the detriment of its citizens), the > > Debian project welcomes this initiative and supports its spirit and > > intent. > > I don't feel comfortable with most of the above paragraph. Where is the > value in kind-of-finger-pointing proprietary software? The intent was to reflect these parts of the original proposal: While proprietary software is developed behind closed doors, Free Software development is done in the open, transparent for everyone. and highlight the difference between FOSS and proprietary software in that regard. I can drop the explicit mention to proprietary software between brackets, though, that's not a problem. > > The Debian project believes Free and Open Source Software Projects to be > > very well positio
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Wed, 15 Nov 2023 at 06:23, Lucas Nussbaum wrote: > > On 15/11/23 at 00:49 +, Luca Boccassi wrote: > > What do you think? Here's what I came up with: > > Hi, > > FWIW, I would likely second something along those lines. Some comments: > > > The Debian project however notes that not enough emphasis has been > > employed in all parts of these regulations to clearly exonerate Free > > and Open Source Software Projects from being subject to the same > > liabilities as commercial products > > I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells > services around a free software product, I think it's OK if they are > covered by this regulation. Maybe it would be better with > s/Projects/Organizations/? > > Maybe we should underline specific borderline situations where the > impact of the regulation would be unclear? I think the two paragraphs are clearer than that already when taken together, especially the last bit which essentially boils down to "let us continue to do what we are doing and go after vendors instead kkthxbye", but what about this rewording: The Debian project however notes that not enough emphasis has been employed in all parts of these regulations to clearly exonerate Free and Open Source Software developers and maintainers from being subject to the same liabilities as commercial vendors, which has caused uncertainty and worry among such stakeholders. Therefore, the Debian project asks the legislators to enhance the text of these regulations to clarify beyond any reasonable doubt that Free and Open Source Software developers and contributors are not going to be treated as commercial vendors in the exercise of their duties when merely developing and publishing Free and Open Source Software, with special emphasis on clarifying grey areas, such as donations, contributions from commercial companies and developing Free and Open Source Software that may be later commercialised by a commercial vendor. It is fundamental for the interests of the European Union itself that Free and Open Source Software development can continue to thrive and produce high quality software components, applications and operating systems, and this can only happen if Free and Open Source Software developers and contributors can continue to work on these projects as they have been doing before these new regulations, without being encumbered by legal requirements that are only appropriate for commercial companies and enterprises. > > , which has caused uncertainty and > > worry among Free and Open Source Software developers and stakeholders. > > > > Therefore, the Debian project requests the legislators to enhance the > > (minor) s/requests/asks/? (can we request the legislators?) Sure, I went back-and-forth a few times myself on that phrasing, switched back.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
worry among Free and Open Source Software developers and stakeholders. Therefore, the Debian project requests the legislators to enhance the text of these regulations to clarify beyond any reasonable doubt that Free and Open Source Software developers and contributors are not going to be treated as commercial vendors, with special emphasis on clarifying grey areas such as donations and contributions from commercial companies. It is fundamental for the interests of the European Union itself that Free and Open Source Software development can continue to thrive and produce high quality software components, applications and operating systems, and this can only happen if Free and Open Source Software developers and contributors can continue to work on these projects as they have been doing before these new regulations, without being encumbered by legal requirements that are only appropriate for commercial companies and enterprises. == Sources: (1) CRA proposals and links: https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation PLD proposals and links: https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive Response from the European Commission to a question from the European Parliament on FOSS awareness: https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html (2) Debian Social Contract No. 2, 3 and 4 https://www.debian.org/social_contract - GENERAL RESOLUTION ENDS - -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 12:57, Aigars Mahinovs wrote: > > True, the employment status is irrelevant. However, in this example Microsoft > will actually have the liability of > providing the security assurances and support for systemd and related > systems, because they are providing > images of such systems as part of their commercial offering on the Azure > cloud platforms. And that will be > true regardless of the employment status of a few developers. > > A company that does not provide any Linux system services to EU customers, > like some integrator operating > just in Canada, would not have such exposure and thus would not incur any > such obligations. Yes, but they have to do that *as part of that commercial product*, which is not systemd, it's whatever product uses it, together with the Linux kernel, glibc, gcc, etc. That's a good thing, and it applies to any corporation that ships any open source software as part of their products. The corporation is responsible for security aspects of said product and its part as shipped in that product, which is great. It doesn't mean that the upstream open source project is now suddenly encumbered as a commercial product out of the blue - which is what the person I was replying to concluded - because it's plainly and obviously not developed solely and exclusively for that commercial offering, given it's used everywhere on any Linux image from any vendor that you can get your hands on by any means.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 12:20, Simon Richter wrote: > > Hi, > > On 13.11.23 19:54, Aigars Mahinovs wrote: > > > So a commercial company releasing open source > > software that is *not* part of their commercial activity (for example a > > router manufacturer releasing an in-house written Git UI) would be > > "supplied outside the course of a commercial activity" and thus not > > subject to this regulation. > > That's why I mentioned systemd in my other email, perhaps I should > elaborate on that. > > The lead developer is employed by Microsoft (who have a certain history > with the EU) and pretty obviously working on it full time. Employment statuses are irrelevant, as said development is not done as part of any commercial product as per relevant legislation as explained already by Aigars, so these points are moot. Mere employment of a developer is not enough to make an open source software a commercial product available on the market.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 10:55, Aigars Mahinovs wrote: > > Let me pipe in here. I have been exposed quite a bit with EU legislation in > the process of our fight against software patents back in 2012. The EU > legislators are quite sensible when the underlying issues are clearly > explained to them, bu the legal language of the documents can be quite dense > and also quite nuanced with one word sometimes completely changing the > meaning of the entire document. > > Looking at > https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454 > > For example the intro clearly states the intent of *not* burdening the open > source development process with the requirements of this directive: >> >> (10) In order not to hamper innovation or research, free and open-source >> software developed or supplied outside the course of a commercial activity >> should not be covered by this Regulation. This is in particular the case for >> software, including its source code and modified versions, that is openly >> shared and freely accessible, usable, modifiable and redistributable. In the >> context of software, a commercial activity might be characterized not only >> by charging a price for a product, but also by charging a price for >> technical support services, by providing a software platform through which >> the manufacturer monetises other services, or by the use of personal data >> for reasons other than exclusively for improving the security, compatibility >> or interoperability of the software. > > For this purpose the following point exists: >> >> (23)‘making available on the market’ means any supply of a product with >> digital elements for distribution or use on the Union market in the course >> of a commercial activity, whether in return for payment or free of charge; > > > Here the "in the course of a commercial activity" is the critical bit. All > volunteer work no longer meets the "making available on the market" > definition and thus all other provisions/definitions no longer apply, because > they all use the "making available on the market" definition directly or > indirectly (via "manufacturer" definition or "product with digital elements" > definitions). Re-read the commercial activity mentioned in the point 10 above > - it is quite explicit that the activity can only be commercial if its > commercial nature is connected with the software in question. So a commercial > company releasing open source software that is *not* part of their commercial > activity (for example a router manufacturer releasing an in-house written Git > UI) would be "supplied outside the course of a commercial activity" and thus > not subject to this regulation. But if they release a WiFi driver that they > also ship to their customers on their routers, that *would* be a commercial > activity and both the open source and the customer version of that driver > would need a safety compliance assessment. > > Even regardless of the specific legal wording in the legislation itself, the > point 10 of the preamble would be enough to to fix any "bug" in the > legislation in post-processing via courts. As in - if any interpretation of > the wording of the directive is indeed found to be hampering open source > development, then it is clearly in error and contrary to the stated intent of > the legislation. This matches precisely my understanding, thank you for stating so clearly and unambiguously what I've been trying to convey (in a much less clear way). > I am *not* objecting to Debian taking such a vote and expressing the stance > intended. However, I expect that it will be seen by the EU legislators with > mifled amusement, because in their context and understanding the legislative > proposal already contains all the necessary protections for open source and > free software development processes. However, if a company (say Amazon or > MySQL) takes an open source product and provides a commercial service based > on that product, then they are expected to also provide security updates, > vulnerability notifications and other relevant services to their customers. > Which is also an intended consequence of the legislation. > > The EU puts the interests of the consumers and of the community above > commercial interests. Even commercial interests of small businesses. Allowing > small businesses to "pollute" the digital environment with insecure or > unmaintained software just because they are small businesses makes no sense > from a European perspective. Indeed. This is good legislation, and the parts you quoted make it exceedingly obvious that the legislators in fact do care about not hampering open source development. It would be very, very strange and self-defeating for the project to come out against this, as the next time around (because if this doesn't pass, something else will - software security in commercial products is too important to leave the current far-west as-is)
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 12 Nov 2023 at 18:11, Ilulu wrote: > Am 12.11.23 um 19:01 schrieb Luca Boccassi: > > Yes - if it's "made available on the market", which is in the first > > bit that was snipped. Pushing a repository on Gitlab is not "making > > available on the market". > > You are wrong. It is. That's why the proposal has: > > "(10d) The sole act of hosting free and open-source software on open > repositories does not in itself constitute making available on the > market of a product with digital elements. As such, most package > managers, code hosting and collaboration platforms should not be > considered as distributors under the meaning of this Regulation." > > ... which means that GITHUB is not responsible for the repo you pushed. Sure, it would be very strange if it was. > But you are. You are the manufacturer of that software product, you make > it available, and whether this is "on the market" = commercial depends > on a lot of things: how many donations you get and from whom, who your > employer is, or who else is working on that repo ... and so on, > depending on how the wording of CRA-Recital 10 will turn out in the end. > You better ask your lawyer. But this is a non-sequitur. I don't see how the fact that Github is not responsible for software hosted on its platform goes to imply that ever such software is a product. Whether something is or is not a product on the market is already quite clear, and the sources cited in the original mail themselves say that the CRA does not change this aspect. There are many, many, many regulations affecting products put on the single market - I've already cited one that should be familiar to everyone, warranties. Are you responsible for the warranty for software you push to Github if someone git clones it? Of course not. Because repositories on Github are not products on the single market.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 12 Nov 2023 at 17:47, Lisandro Damián Nicanor Pérez Meyer wrote: > > Hi, > > On Sun, 12 Nov 2023 at 14:35, Ilulu wrote: > > > [snip] > > (10a) For example, a fully decentralised development model, where no > > single commercial entity exercises control over what is accepted into > > the project’s code base, should be taken as an indication that the > > product has been developed in a non-commercial setting. On the other > > hand, where free and open source software is developed by a single > > organisation or an asymmetric community, where a single organisation is > > generating revenues from related use in business relationships, this > > should be considered to be a commercial activity. Similarly, where the > > main contributors to free and open-source projects are developers > > employed by commercial entities and when such developers or the employer > > can exercise control as to which modifications are accepted in the code > > base, the project should generally be considered to be of a commercial > > nature. > > So basically this means Qt will be considered a commercial product > _even_ if it's totally open source (at least in the way we ship it in > Debian). Even more, it can even be argued that if we ship it _and_ I > get to patch it (we do), then I might be responsible for it, which to > me makes no sense at all. Yes - if it's "made available on the market", which is in the first bit that was snipped. Pushing a repository on Gitlab is not "making available on the market". Selling QT as a supported toolkit to third parties that then integrate it in their products or services or use it internally, is. If you do the former, nothing changes for you. If you do the latter, then you are affected - and that's a _good_ thing!
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 12 Nov 2023 at 17:35, Ilulu wrote: > > Am 12.11.23 um 18:09 schrieb Luca Boccassi: > > We do know whether something is commercial or not though ... > > I sincerely doubt that. Just to illustrate this I'm citing a part (only > a part) of one of the regulation drafts which are presently considered > in trilogue. > > "(10) Only free and open-source made available on the market in the > course of a commercial activity should be covered by this Regulation. > Whether a free and open-source product has been made available as part > of a commercial activity should be assessed on a product-by-product > basis, looking at both the development model and the supply phase of the > free and open-source product with digital elements. > (10a) For example, a fully decentralised development model, where no > single commercial entity exercises control over what is accepted into > the project’s code base, should be taken as an indication that the > product has been developed in a non-commercial setting. On the other > hand, where free and open source software is developed by a single > organisation or an asymmetric community, where a single organisation is > generating revenues from related use in business relationships, this > should be considered to be a commercial activity. Similarly, where the > main contributors to free and open-source projects are developers > employed by commercial entities and when such developers or the employer > can exercise control as to which modifications are accepted in the code > base, the project should generally be considered to be of a commercial > nature. > (10b) With regards to the supply phase, in the context of free and > open-source software, a commercial activity might be characterized not > only by charging a price for a product, but also by charging a price for > technical support services, when this does not serve only the > recuperation of actual costs, by providing a software platform through > which the manufacturer monetises other services, or by the use of > personal data for reasons other than exclusively for improving the > security, compatibility or interoperability of the software. Accepting > donations without the intention of making a profit should not > count as a commercial activity, unless such donations are made by > commercial entities and are recurring in nature." That all looks exceedingly clear to me: if you are selling a product or a service, then just because the software is free software doesn't exempt you from being liable for its security. That's good! Great, even. If a for-profit private company, say, sells a phone running Debian, just because Debian is open source doesn't mean it should get away with not providing security support to its customers. Just as it doesn't discount it from the minimum warranty period - if you buy the phone and it doesn't work, they can't just say "sorry it's the open source software's fault, no refund/exchange", and so on. It seems clear to me what the intent of the legislators is here: avoid loopholes. Another ad-absurdum: if Microsoft were to push all the code behind Azure to Github, it shouldn't mean that it should be exempt from providing security support to its customers according to this legislation, just because it's open source. That sounds like a good thing to me! As far as I can see, the key thing here is always that there's a product put on the single market. Pushing a repository to Github is not putting a product on the market. Publishing Debian images on debian.org is not putting a product on the market. Selling a service that uses a Debian image is - and then the service provider is the party responsible.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 12 Nov 2023 at 17:29, Scott Kitterman wrote: > On November 12, 2023 5:09:26 PM UTC, Luca Boccassi wrote: > >On Sun, 12 Nov 2023 at 15:10, Santiago Ruano Rincón > > wrote: > >> > >> Dear Debian Fellows, > >> > >> Following the email sent by Ilu to debian-project (Message-ID: > >> <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have > >> discussed during the MiniDebConf UY 2023 with other Debian Members, I > >> would like to call for a vote about issuing a Debian public statement > >> regarding > >> the EU Cyber Resilience Act (CRA) and the Product Liability Directive > >> (PLD). The CRA is in the final stage in the legislative process in the > >> EU Parliament, and we think it will impact negatively the Debian > >> Project, users, developers, companies that rely on Debian, and the FLOSS > >> community as a whole. Even if the CRA will be probably adopted before > >> the time the vote ends (if it takes place), we think it is important to > >> take a public stand about it. > >> > >> - GENERAL RESOLUTION STARTS - > >> > >> Debian Public Statement about the EU Cyber Resilience Act and the > >> Product Liability Directive > >> > >> The European Union is currently preparing a regulation "on horizontal > >> cybersecurity requirements for products with digital elements" known as > >> the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > >> phase of the legislative process. The act includes a set of essential > >> cybersecurity and vulnerability handling requirements for > >> manufacturers. > >> It will require products to be accompanied by information and > >> instructions to the user. Manufacturers will need to perform risk > >> assessments and produce technical documentation and for critical > >> components, have third-party audits conducted. Discoverded security > >> issues will have to be reported to European authorities within 24 hours > >> (1). The CRA will be followed up by the Product Liability Directive > >> (PLD) which will introduce compulsory liability for software. More > >> information about the proposed legislation and its consequences in (2). > > > >These all seem like good things to me. For too long private > >corporations have been allowed to put profit before accountability and > >user safety, which often results in long lasting damage for citizens, > >monetary or worse. It's about time the wild-west was reined in. > > > >> While a lot of these regulations seem reasonable, the Debian project > >> believes that there are grave problems for Free Software projects > >> attached to them. Therefore, the Debian project issues the following > >> statement: > >> > >> 1. Free Software has always been a gift, freely given to society, to > >> take and to use as seen fit, for whatever purpose. Free Software has > >> proven to be an asset in our digital age and the proposed EU Cyber > >> Resilience Act is going to be detrimental to it. > >> a. It is Debian's goal to "make the best system we can, so that > >> free works will be widely distributed and used." Imposing requirements > >> such as those proposed in the act makes it legally perilous for others > >> to redistribute our works and endangers our commitment to "provide an > >> integrated system of high-quality materials _with no legal > >> restrictions_ > >> that would prevent such uses of the system". (3) > > > >Debian does not sell products in the single market. Why would any > >requirement be imposed, how, and on whom? SPI? Debian France? > > > >> b. Knowing whether software is commercial or not isn't feasible, > >> neither in Debian nor in most free software projects - we don't track > >> people's employment status or history, nor do we check who finances > >> upstream projects. > > > >We do know whether something is commercial or not though - for > >example, we don't have to provide Debian with warranty to our users, > >because we know publishing images on debian.org is not a commercial > >activity. > >The second statement I find hard to follow, what would employment > >status have to do with this? > > > >> c. If upstream projects stop developing fo
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 12 Nov 2023 at 15:10, Santiago Ruano Rincón wrote: > > Dear Debian Fellows, > > Following the email sent by Ilu to debian-project (Message-ID: > <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have > discussed during the MiniDebConf UY 2023 with other Debian Members, I > would like to call for a vote about issuing a Debian public statement > regarding > the EU Cyber Resilience Act (CRA) and the Product Liability Directive > (PLD). The CRA is in the final stage in the legislative process in the > EU Parliament, and we think it will impact negatively the Debian > Project, users, developers, companies that rely on Debian, and the FLOSS > community as a whole. Even if the CRA will be probably adopted before > the time the vote ends (if it takes place), we think it is important to > take a public stand about it. > > - GENERAL RESOLUTION STARTS - > > Debian Public Statement about the EU Cyber Resilience Act and the > Product Liability Directive > > The European Union is currently preparing a regulation "on horizontal > cybersecurity requirements for products with digital elements" known as > the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > phase of the legislative process. The act includes a set of essential > cybersecurity and vulnerability handling requirements for manufacturers. > It will require products to be accompanied by information and > instructions to the user. Manufacturers will need to perform risk > assessments and produce technical documentation and for critical > components, have third-party audits conducted. Discoverded security > issues will have to be reported to European authorities within 24 hours > (1). The CRA will be followed up by the Product Liability Directive > (PLD) which will introduce compulsory liability for software. More > information about the proposed legislation and its consequences in (2). These all seem like good things to me. For too long private corporations have been allowed to put profit before accountability and user safety, which often results in long lasting damage for citizens, monetary or worse. It's about time the wild-west was reined in. > While a lot of these regulations seem reasonable, the Debian project > believes that there are grave problems for Free Software projects > attached to them. Therefore, the Debian project issues the following > statement: > > 1. Free Software has always been a gift, freely given to society, to > take and to use as seen fit, for whatever purpose. Free Software has > proven to be an asset in our digital age and the proposed EU Cyber > Resilience Act is going to be detrimental to it. > a. It is Debian's goal to "make the best system we can, so that > free works will be widely distributed and used." Imposing requirements > such as those proposed in the act makes it legally perilous for others > to redistribute our works and endangers our commitment to "provide an > integrated system of high-quality materials _with no legal restrictions_ > that would prevent such uses of the system". (3) Debian does not sell products in the single market. Why would any requirement be imposed, how, and on whom? SPI? Debian France? > b. Knowing whether software is commercial or not isn't feasible, > neither in Debian nor in most free software projects - we don't track > people's employment status or history, nor do we check who finances > upstream projects. We do know whether something is commercial or not though - for example, we don't have to provide Debian with warranty to our users, because we know publishing images on debian.org is not a commercial activity. The second statement I find hard to follow, what would employment status have to do with this? > c. If upstream projects stop developing for fear of being in the > scope of CRA and its financial consequences, system security will > actually get worse instead of better. Why would projects stop developing? If it's a product sold on the single market, then it's right that it is subject to these rules. If it's not a product, then these rules don't affect it, just like rules on warranties. > d. Having to get legal advice before giving a present to society > will discourage many developers, especially those without a company or > other organisation supporting them. Same as above. If you are not selling anything, why would you need legal advice, any more than you already do? The EU Single Market has many, many rules, this is not the first and won't be the last. > 2. Debian is well known for its security track record through practices > of responsible disclosure and coordination with upstream developers and > other Free Software projects. We aim to live up to the commitment made > in the Social Contract: "We will not hide problems." (3) >
Re: Changing how we handle non-free firmware
On Thu, 2022-08-18 at 22:29 +0200, Tobias Frost wrote: > On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: > > Hi a11! > > > > I'm proposing to change how we handle non-free firmware in > > Debian. I've written about this a few times already this year [1, > > 2] > > and I ran a session on the subject at DebConf [3]. > > > > TL;DR: The way we deal with (non-free) firmware in Debian isn't > > great. For a long time we've got away without supporting and > > including > > (non-free) firmware on Debian systems. We don't *want* to have to > > provide (non-free) firmware to our users, and in an ideal world we > > wouldn't need to. However, it's no longer a sensible path when > > trying > > to support lots of common current hardware. Increasingly, modern > > computers don't function fully without these firmware blobs. > > > > Since I started talking about this, Ansgar has already added dak > > support for a new, separate non-free-firmware component - see > > [4]. This makes part of my original proposal moot! More work is > > needed > > yet to make use of this support, but it's started! :-) > > > > I believe that there is reasonably wide support for changing what > > we > > do with non-free firmware. I see several possible paths forward, > > but > > as I've stated previously I don't want to be making the decision > > alone. I believe that the Debian project as a whole needs to make > > the > > decision on which path is the correct one. > > > > I'm *not* going to propose full text for all the possible choices > > here; as eloquently suggested by Russ [5], it's probably better to > > leave it for other people to come up with the text of options that > > they feel should also be on the ballot. > > > > So, I propose the following: > > > > = > > > > We will include non-free firmware packages from the > > "non-free-firmware" section of the Debian archive on our official > > media (installer images and live images). The included firmware > > binaries will *normally* be enabled by default where the system > > determines that they are required, but where possible we will > > include > > ways for users to disable this at boot (boot menu option, kernel > > command line etc.). > > > > When the installer/live system is running we will provide > > information > > to the user about what firmware has been loaded (both free and > > non-free), and we will also store that information on the target > > system such that users will be able to find it later. The target > > system will *also* be configured to use the non-free-firmware > > component by default in the apt sources.list file. Our users should > > receive security updates and important fixes to firmware binaries > > just > > like any other installed software. > > > > We will publish these images as official Debian media, replacing > > the > > current media sets that do not include non-free firmware packages. > > > > = > > > > A reason for defaulting to installing non-free firmware *by > > default* > > is accessibility. A blind user running the installer in text-to- > > speech > > mode may need audio firmware loaded to be able to drive the > > installer > > at all. It's going to be very difficult for them to change this. > > Other > > people should be able to drive the system (boot menus, etc.) to > > *not* > > install the non-free firmware packages if desired. > > > > We will *only* include the non-free-firmware component on our media > > and on installed systems by default. As a general policy, we still > > do > > not want to see other non-free software in use. Users may still > > enable > > the existing non-free component if they need it. > > > > We also need to do the work to make this happen: > > > > * in d-i, live-boot and elsewhere to make information about > > firmware > > available. > > > > * add support for the non-free-firmware section in more places: > > ftpsync, debian-cd and more. > > > > and I plan to start on some of those soon. > > > > [1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do > > [2] https://lists.debian.org/debian-devel/2022/04/msg00130.html > > [3] > > https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/ > > [4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable > > [5] https://lists.debian.org/debian-devel/2022/04/msg00214.html > > > > -- > > Steve McIntyre, Cambridge, UK. > > st...@einval.com > > You raise the blade, you make the change... You re-arrange me 'til > > I'm sane... > > Thanks Steve for this going forward! > (seconded.) Looks great, thank you Steve - seconded. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
