tho...@goirand.fr writes:
> There may be some edge cases. What if a country decided to forbid
> shipping youtube downloaders ? Or gambling software ?
Or cryptographic algorithms that do not have government back doors.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
public library probably goes too far, in
that we are trying to create a unified distribution and don't have the
same public mission of collecting as broad of a range of human expression
as possible, but I think there's some part of the same basic impetus at
work.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e through in ways that weren't productive
or particularly respectful.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I don't
think we know whether non-free firmware contains machine learning models
and therefore aren't really in a position to make rules about that).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
use of the
work (including but not limited to the kind of statistical extraction done
by LLM training) should be trained on consentual training data. The
license of the training data is how the free software community
establishes creator consent.
There is space here for machine learning models tha
m that is being used as an unwitting tool by
the richest people on the planet who resent that art currently (unevenly,
imperfectly) favors labor over capital, and whose goal is to ensure
capital reigns surpreme in all areas of society.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r morals and
ethical judgments and find some of them wanting.
The ironic part is that this makes me sound like some sort of
conservative, when I am probably on the left radical side of most of the
folks here. But I want to argue for changing things thoughtfully and
arguing seriously about a sense of s
st for human beings, not
corporate constructs. That is the entire point of the free software
movement.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hurt in the process, I think your
politics are an active danger to people I care about and I will do what I
can to oppose you.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g free software rules to training data is a bit of a heavy hammer
and maybe it's too much, but it does hold an ethical line about consent
that I think we should hold. Maybe there's a different way to hold that
line, and I'm open to being convinced by a different approach, but I don't
want to give up this ethical line completely.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ght decision and I also hope it doesn't discourage
you from continuing to work on this. I don't think anyone is saying that
we shouldn't have this conversation and a vote, only that we (myself very
much included) are realizing that we hadn't actually thought this through
as thorou
in my opinion. But I
guess I would have expected us to do that via a mechanism similar to
non-free-firmware if we wanted to make it easy for users to use software
that is OSAID-approved but not DFSG-free, at least if we have a lot of it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Clint Adams writes:
> On Tue, May 06, 2025 at 08:36:50AM -0700, Russ Allbery wrote:
>> Well, first, I continue to object to the idea that a model can be
>> DFSG-free if it's trained on non-DFSG-free data. I think that makes it
>> definitionally non-free. (I have read
hould fix those bugs (but perhaps less urgently than fixing bugs
where the code itself is not free).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
still want us to remain flexible around edge cases and interpret the
DFSG as humans and not like a computer program, but licenses are a
sufficiently obvious exception that I think we should ideally spell that
out, along with anything else that's similarly substantial and common.
Stefano Zacchiroli writes:
> On Mon, May 05, 2025 at 02:13:58PM -0700, Russ Allbery wrote:
>> However, I am very leery about extending that exception to cases where
>> people are intentionally creating that situation by deleting the input
>> data on purpose.
I should
the only test for compliance with the
DFSG. The point of the DFSG is more than to *only* put everyone on an
equal footing. There is also a straightforward desire to actually have
meaningful and useful source code, without which free software is kind of
pointless.
--
Russ Allbery (r...@debian.org)
other projects that can distribute it.
Obviously, this is just my opinion, and I realize other people disagree.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
including to avoid disruptive internal conflict, and that does not carry
any project-wide judgment on the things we have decided to not actively
support.
> Will that benefit the development of a freer and more accessible AI
> landscape?
This is not a goal of the Debian Project at
gy for what we're currently talking
about might be "machine learning model," which encompasses a wider set of
onstructions from processed training data without limiting them to only
large-language models.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ource code be in main,
not off somewhere else where we promise it exists, really (but which is
not under our control). We have historically not applied that to the
training data for models, and maybe that's correct, but the correctness of
that position is certainly not obvious to me from
ith novel security flaws that
researchers are only starting to explore. I think the chances are high
that their security will get much, much worse before it gets better. It is
one of the many reasons why I am generally an LLM skeptic.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Debian, and the current LLM craze is a good
opportunity to clean house and reaffirm a strict free software policy
including training data. I'm rather sympathetic to that argument, frankly,
just because the simplicity of the "source code for everything, no
exceptions" position is comfortable in my brain. But we should be fairly
sure about what we're agreeing to before making that decision.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
AI models embedded in firmware. I wouldn't expect
those to be common, but it seems likely that at least one will show up at
some point.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ine learning applications like
that we may have lurking around. I also have no strong opinion about what
we should do with such packages, to be clear; this should not be taken as
an objection to the proposed GR.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Adam Majer writes:
> On 7/7/24 21:53, Russ Allbery wrote:
>> I consider it an ethical obligation as someone who works in security to
>> object whenever people make these types of absolute statements about
>> security properties. Security is almost always a trade off. Y
y is almost always a trade off. You can
usually get more security by trading off functionality, up to the obvious
end point of securing a computer by turning it off. The best point to
occupy on that trade-off curve is a hard question that always involves
more factors than only security.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
If some new attack implementation on SHA1 appears, that isn't detected
> by your SHA1CD variant, your validation can be by-passed.
This is true.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
undant (I think they're
both signed by t2u since presumably they're in *.changes).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Aigars Mahinovs writes:
> On Sun, 30 Jun 2024 at 17:58, Russ Allbery wrote:
>>> The second file consists of a shallow git clone of the repository for
>>> the tag that t2u wants to upload, put into an appropriately named
>>> tarball.
>> Just to double chec
> requirements as the thing proposed here. (Summarized as detached
> signature from the DD/DM over the tree of the tag, and that tree/tags
> data available in a file beside the upload).
Oh, yeah, for sure, none of the details now should block future
improvements worked out in the normal way.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> As soon as I start using tag2upload, I am no longer running dgit locally
> and that patch generation will be represented in the Git tree that I
> sign to trigger tag2upload.
That patch generation will *not* be represented in the Git tree that I
sign to trigger t
ign to trigger
tag2upload.
Ian explained all of this in an excellent and comprehensive message that
he sent in reply to mine, correcting my misunderstandings about how this
workflow worked. (Hopefully I have it right now!)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2uplo
Ansgar 🙀 writes:
> On Thu, 2024-06-27 at 09:15 -0700, Russ Allbery wrote:
>> *As soon as* you indicated that there was some willingness to move your
>> position, people reinvested substantial effort into trying to have that
>> discussion
> Yes, I remember. For examp
ly about Debian at all.
If you think there's something more to discuss that would help you change
your mind, the GR isn't happening tomorrow. But there has to be an end in
sight. Doing things in Debian cannot be an endless series of procedural
hoops, beyond which is simply more procedural hoops.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon Richter writes:
> On 6/27/24 00:41, Russ Allbery wrote:
>> The second case seems fine with tag2upload? Particularly if upstream
>> signs the Git tag. Instead of pointing to a possibly signed release
>> tarball, the tag2upload tag points to a signed upstream Git tag.
cess for one reason or
another. But there are a lot of upstreams for which this is not the case.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Jun MO writes:
> Russ Allbery writes:
>> For the third purpose, I believe only weak intent information can be
>> derived from the uploader signature today. It is common practice in
>> Debian to verify the Git tree that one wants to upload, run a package
>> build step
r the thing
that happens approximately never. The attacker knows all of this, and
will choose their attack strategy accordingly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tho...@goirand.fr writes:
> On Jun 25, 2024 5:50 PM, Russ Allbery wrote:
>> The tag2upload proposal moves the source package build from 1 to 2.
> NO ! That is NOT what you are proposing. There's been a 10 years long
> effort to have package reproducibility, your proposal i
e correct
me if I have this wrong.) My recollection is that the source package
build is normally done outside sbuild and then copied into it.
> I'm opposed to trusting only a signed git tag in your proposed
> implementation, when it has been proven we can do much better.
"Proven&qu
Russ Allbery writes:
> HW42 writes:
>> And, if yes: Why wouldn't they do the equivalent with the sources in
>> git (work on the less trusted system, transfer commits (git push/pull)
>> to the system with signing access and sign there, without review)?
> They wi
HW42 writes:
> Russ Allbery:
>> For the third purpose, I believe only weak intent information can be
>> derived from the uploader signature today. It is common practice in
>> Debian to verify the Git tree that one wants to upload, run a package
>> build step, and then
HW42 writes:
> Russ Allbery:
>> This attack is not equivalent to compromise of the uploader's OpenPGP
>> key, which neither upload architecture defends against. Many Debian
>> uploaders build source packages on less-trusted systems where they also
>> build and tes
rly if they are ongoing (in other words, not just on initial
upload, but periodically pulling all the source packages in the archive
and reproducing them again).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s worth noting for comparison purposes that a compromise of a binary
buildd is even harder to detect, since it leaves no trace in the archive
at all apart from the malicious binary package.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Scott Kitterman writes:
> On Sunday, June 23, 2024 11:43:47 AM EDT Russ Allbery wrote:
>> You are entitled to believe that my analysis is wrong. You are not
>> entitled to claim that I didn't do the work that I did, quite publicly
>> and openly, right here on this ma
Scott Kitterman writes:
> On Sunday, June 23, 2024 11:48:09 AM EDT Russ Allbery wrote:
>> As mentioned in the summary, I believe we've found a resolution to this
>> problem provided that the FTP team is willing to implement the protocol
>> I described in dak, which A
binary buildd:
start from an independently-verified maintainer-signed thing and produce a
build artifact.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I did, quite publicly and
openly, right here on this mailing list for everyone to see.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
going commitments but not delegations. But I can also see the
argument for considering that a bug and wanting a delegation for any new
ongoing service.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Matthias Urlichs writes:
> On 23.06.24 04:45, Russ Allbery wrote:
>> that just feels wrong to me. Rude. Dismissive. And self-defeating
>> for Debian as a whole.
> 100% agree. Though again: that *feels* rude and dismissive. I'm *not*
> ascribing *intent* to be rud
o longer
participating, but I will cheer you on from the sidelines, very sincerely.
I want you to succeed.
But, in the meantime, I want to deploy the work that is already done and
that will make my life better today. And I would ask people to consider
the serious possibility, based on a lot of pas
Ian Jackson writes:
> Russ Allbery writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>> So yes, you're right, the git-debrebase example is not nearly as
>> interesting as I had thought because the tooling works differently than
>> I had realized.
es. tag2upload by design does not
require that workflow change, although it does make it easier.
# Disclaimer
Again, this summary is only my opinion. I am not a tag2upload maintainer,
nor is the draft GR my GR. I cannot speak for any of the parties involved
here, only for myself.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
y like that better. There is an obligation that comes with
the delegate position to only block things for clear and important reasons
that matter, and to do that, one also has to be *correct*. If I make a
delegate decision on an incorrect basis, I am wrong and I can and should
be overridden.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
n the names of the source packages and my memory is not clear enough
to throw up good search terms. Maybe someone else has a link for you.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e Joerg asked to keep talking about it for a bit longer).
As things currently stand, though, a GR is still the only path forward.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Ansgar 🙀 writes:
> On Fri, 2024-06-21 at 08:29 -0700, Russ Allbery wrote:
>> Wait, why would I ever want to upload a 3.0 (native) package for a
>> non-native package with the tooling as it is today in Debian?
> As far as I understand this whole thread is about changing the to
t to trust this piece
of project infrastructure to do this for me," you're saying no, you're not
allowed to do that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
have a long
list of work ahead of you and problems to resolve before anyone else can
reasonably take advantage of that change.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
(Trimming the cc list a bit to keep from deluging people who aren't
actively participating in this part of the conversation.)
Ansgar 🙀 writes:
> On Wed, 2024-06-19 at 16:06 -0700, Russ Allbery wrote:
>> I appreciate that you're trying really hard to find a way to repres
Ansgar 🙀 writes:
> On Wed, 2024-06-19 at 14:43 -0700, Russ Allbery wrote:
>> I don't think it's bad in any inherent way, but it's not tag2upload.
>> It's not the thing that the developers have been working on, it doesn't
>> solve the problems they
Joerg Jaspert writes:
> On 17265 March 1977, Russ Allbery wrote:
>> I wish it wouldn't change what package maintainers do, but the only way
>> I think that works is to interpose a relatively complex build step
>> between the maintainer representation and the archive
(Trimming down the cc list because I think the topic in this corner of the
thread is different.)
Bastian Blank writes:
> On Wed, Jun 19, 2024 at 11:18:36AM -0700, Russ Allbery wrote:
>> Similarly, I'm not sure a source package based on Git avoids the need
>> for a source
Ansgar 🙀 writes:
> On Wed, 2024-06-19 at 11:18 -0700, Russ Allbery wrote:
>> (And in case you're now wondering whether tag2upload can just bifurcate
>> here and produce 3.0 (native) for patches-applied and 3.0 (quilt) for
>> patches-unapplied, I don't think th
Ansgar 🙀 writes:
> On Wed, 2024-06-19 at 08:39 -0700, Russ Allbery wrote:
>> Sure, we could tell people to use 3.0 (native) for everything with
>> Debian changes to the upstream source and stop trying to use 3.0
>> (quilt). You're not the first person to make that
Ansgar 🙀 writes:
> On Wed, 2024-06-19 at 07:45 -0700, Russ Allbery wrote:
>> No, the uploader doesn't know this. Some of the files (the ones in
>> debian/patches) are synthesized from Git commits and do not exist at
>> all in the checkout of the Git tree, which w
Russ Allbery writes:
> Ansgar 🙀 writes:
>> It doesn't require dak to reproduce whatever steps tag2upload runs to
>> generate the .dsc from that or source packages to be reproducible; the
>> uploader only needs to know which files end up in the source package,
>
Ansgar 🙀 writes:
> On Tue, 2024-06-18 at 18:25 -0700, Russ Allbery wrote:
>> Integrity verification of the source package construction by dak was
>> the part of this that I was the most worried about, because that's the
>> place where it had looked like the tag2uplo
ages).
Yes, I do think roughly the right way to think about tag2upload is that
it's a source package buildd, where the "source of the source package" is
a signed Git tree.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Joerg Jaspert writes:
> On 17265 March 1977, Russ Allbery wrote:
>> Does anyone think I've missed anything?
> Yah. About the whole first half of my mail.
I don't understand. Are you saying that if dak checks the signature on
the tag, you no longer need to check an upl
I very much hope that you're feeling better! And once again I really
appreciate your messages in this discussion. I think they have been very
helpful in clarifying the FTP team position.
Joerg Jaspert writes:
> On 17263 March 1977, Russ Allbery wrote:
>> What signed artifac
nd the
same Git tag, verified the original signature, reproduced the source
package build, and got the same results.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tions about the timeline, I would have phrased several of my
messages here differently. This is entirely my fault.
So far, from this thread, it looks like the decision from 2019 may still
stand, but I think there are still places to explore.
Joerg Jaspert writes:
> On 17261 March 1977, Russ
re trying to solve at the time.
The compromise was to strongly suggest that anyone who was going to
propose a GR on a topic that was controversial and not urgent post a draft
first and allow a generous period of time for preliminary discussion. I
think this is that system working as designed, speaki
a security benefit.
> All you can vet is that the tag2upload service claims it does. You may
> think that's better, but neither of them are entirely free of risk.
I completely agree with this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Louis-Philippe Véronneau writes:
> On 2024-06-16 2 h 23 p.m., Russ Allbery wrote:
>> For the existing source package signatures, a simplified sequence looks
>> like this:
>> human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive
>> For tag2uplo
Simon Josefsson writes:
> Russ Allbery writes:
>> But it's not independent; tag2upload makes this story somewhat better.
>> tag2upload is based on a signed Git tag and moves the source package
>> construction off of the uploader's system onto more-secure project
or the Git tree that they signed. If that
blows up, it's their responsibility to help clean up the mess.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
very specific
implementation detail that does not prove what you seem to think it
proves.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
for doing
this correctly and threatening them with consequences for not doing it
correctly only slightly decreases the risk of failure.
This is exactly why reproducible builds are so important: that involves
finding a way for computers to do the sorts of repetitive validation tasks
that computer
neither case can the source package signature be traced back to a
human, which is what I am arguing makes them similar. What we're arguing
about is which system has the better design (both security and otherwise)
for the pieces prior to (2) in the first case and (3)/(1) in the second
case.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the provenance back further to a signed Git tree, something
that's not possible in the general case with source packages today. This
has various security trade offs as discussed above. But I do not agree
that it breaks the property that you claim it breaks; in both cases, you
can trace the source package back to the entity responsible for its
construction.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
my
intent was to say that I didn't think tag2upload changed the problem one
way or the other. I think some of that got lost in editing.
Maybe I'm missing some reason why tag2upload is more vulnerable to attacks
of this type, though?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Matthias Urlichs writes:
> On 15.06.24 00:37, Russ Allbery wrote:
>> dak should not be doing the source package transformation, because that
>> is a much more complicated process and therefore a larger security
>> attack surface. That's why it's done in a sandb
at this will indeed produce the
> source package from the signed Git tag.
I believe that's what tag2upload pushes to the dgit-repos server, although
I'm not sure that exactly matches what you're asking for.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hink something like that would go a long way towards
providing some really interesting security properties.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
we can get more
assurance that the source package construction was done properly than
that; we don't have to trust that the uploader's local system did it
properly (at least in the not-universal case of packages well-served by
the tag2upload protocol).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
missing some security control in dak, which is
entirely possible because I've not done a comprehensive security review of
dak and am not certain of all the details of the architecture. If I'm
missing something, please do correct me!)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ay whether that would be
all you need, and I'm not sure it is. I couldn't convince myself that you
could ignore file permissions, symlinks, hard links, and so forth.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r signs is not
clearly better (and I think arguably worse) than having two tag2upload
servers in separate security domains that perform the same operations. In
both cases you're still trusting the same code to perform the source
package transformation, but the tag2upload server has a better security
model than the uploader's local system.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e for
uploading without checking the contents of the git clone separately, there
is exactly the same window of vulnerability.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
developers would be the very
first people to turn the service off until they can figure out how to fix
the vulnerability. Everyone involved in this discussion cares deeply
about not compromising the security of the archive.
At the end of the day, it's just code. Most code problems are fi
Scott Kitterman writes:
> On Friday, June 14, 2024 5:25:33 PM EDT Russ Allbery wrote:
>> It requires that the signature on the Git tag be correctly checked and
>> that fingerprint be put into the *.dsc file, yes.
>> It doesn't require that dak then also trust the au
previous posts to this thread
and your refusal to provide any detail about the security vulnerabilities
that you believe exist, I simply do not trust that your assertions are
true without something concrete that I can understand. If you want me to
take your assertions seriously, you're going t
aging on the actual
tarball as released. And it would let us reuse the upstream signature on
the tarball, which is useful in some cases to provide a bit of additional
provenance and tracing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Ansgar 🙀 writes:
> On Fri, 2024-06-14 at 11:45 -0700, Russ Allbery wrote:
>> Sorry, I don't understand. What isn't complete? I just explained how
>> dak could continue to enforce all the same authorization checks as it
>> does today. This is part of t
Scott Kitterman writes:
> On Friday, June 14, 2024 2:45:55 PM EDT Russ Allbery wrote:
>> Sorry, I don't understand. What isn't complete? I just explained how
>> dak could continue to enforce all the same authorization checks as it
>> does today. This is part
1 - 100 of 648 matches
Mail list logo
