Git and SHA1 collisions (Was: Re: Validating tarballs against git repositories)

[Gioele Barabucci]

On 30/03/24 23:09, Simon Josefsson wrote:

Russ Allbery  writes:

Simon Josefsson  writes:

Sean Whitton  writes:



We did some analysis on the SHA1 vulnerabilities and determined that
they did not meaningfully affect dgit & tag2upload's design.



Can you share that analysis?  As far as I understand, it is possible for
a malicious actor to create a git repository with the same commit id as
HEAD, with different historic commits and tree content.  I thought a
signed tag is merely a signed reference to a particular commit id.  If
that commit id is a SHA1 reference, that opens up for ambiguity given
recent (well, 2019) results on SHA1.  Of course, I may be wrong in any
of the chain, so would appreciate explanation of how this doesn't work.


I believe you're talking about two different things.  I think Sean is
talking about preimage resistance, which assumes that the known-good
repository is trusted, and I believe Simon is talking about manufactured
collisions where the attacker controls both the good and the bad
repository.


Right.  I think the latter describes the xz scenario: someone could have
pushed a maliciously crafted commit with a SHA1 collision commit id, so
there are two different git repositories with that commit id, and a
signed git tag on that commit id authenticates both trees, opening up
for uncertainty about what was intended to be used.  Unless I'm missing
some detail of how git signed tag verification works that would catch
this.


Git contains a couple of countermeasures meant to greatly reduce the 
practical feasibility of such manipulations.


The first is the fact that it uses a hardened SHA-1 function that 
produces different hashes when it is fed one of the known collision 
seeds ("disturbance vectors"). This hardened version of SHA-1 is only 
resistant against known attacks, but it substantially raises the bar 
from "use one of these files downloaded from the Web" to "set up your 
own collision generator that will work only once for this specific 
attack and once discovered will no longer work".


From https://lwn.net/Articles/716093/


Git can be configured with the USE_SHA1DC build time configuration
variable to use SHA-1 implementation from shattered.io that detects
attempted collisions

From https://shattered.io/


Is Hardened SHA-1 vulnerable? No, SHA-1 hardened with
counter-cryptanalysis (see ‘how do I detect the attack’) will detect
cryptanalytic collision attacks.


The second countermeasure is the fact that if two objects (e.g., 
commits) happen to have the same hash, then Git will use the one it has 
seen first. In the common case in which the original author has pushed a 
commit and the attacker subsequently pushed a malicious version of that 
commit with the same hash, then all people that fetch that repository 
will always see (as in, write to disk during a checkout) the original 
version, not the malicious version. The malicious version will still be 
in the git pack, but git will ignore it.


From https://marc.info/?l=git=115678778717621=2

Nope. If it has the same SHA1, it means that when we receive the 
object from the other end, we will _not_ overwrite the object we 
already have. […] if we ever see a collision, the "earlier" object

in any particular repository will always end up overriding


With these countermeasures in places, in order to successfully pull a 
collusion attack, the attacker must:


1. Create an unseen collision seed.
2. Have access to the server that hosts the official repo to remove 
traces of the original commit.

3. Hope that nobody pulled the repo before they tampered it.
4. Hope that nobody will notice a series of random characters being 
shown during operations like git log -p.


Sure, SHA1 is broken, should be avoided and not relied upon. And many 
people can easily see how to work around the countermeasures put in 
place by SHA1.


But pulling a successful collision attack is not a trivial task. For 
instance, the xz attacker did not have all that was required to carry it 
out (for example they had no direct access to the git servers... yet).


Regards,

--
Gioele Barabucci

Re: xz backdoor

[Todd Zullinger]

Diane Trout wrote:
> On Sun, 2024-03-31 at 03:34 +0100, Wookey wrote:
>> On 2024-03-30 20:52 +0100, Ansgar  wrote:
>>> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
>>> Possibly also TPM modules in computers.
>>> 
>>> These can usually be used for both OpenPGP and SSH keys.
>> 
>> Slightly off-topic, but a couple of recent posts have given me the
>> same thought:
>> 
>> Can someone point to good docs on this?  I've had a
>> yubikey for 3/4 of a year now but have not yet worked out
>> how I put my GPG key in it.  (or if it should be another
>> key, or a subkey, or whatever). So I'm not actually using
>> it yet.
> 
> I've also been thinking I needed to this, and so far this has looked
> like the most detailed write up I've found so far.

Another useful source is the "Protecting code integrity with
PGP" from the Linux Foundation IT folks:

https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md

It's a bit less daunting than the drduh guide, which can be
helpful for folks who aren't subject-matter experts and just
want a reasonable "how do I make this work" guide. :)

> I haven't followed the advice but I've been working on trying to
> understand it.
> 
> https://github.com/drduh/YubiKey-Guide

-- 
Todd


signature.asc
Description: PGP signature

Re: Some t64 libraries already in testing; I'm confused

[Andreas Metzler]

On 2024-03-30 Julian Gilbey  wrote:
> My very limited understanding of this major transition was that the
> t64 libraries are being held in unstable until (almost) everything is
> ready, at which point there will be a coordinated migration into
> testing.  But I've now been asked to upgrade something on my testing
> machine which pulls in a t64 library.  Has something slipped through
> the net, or is this intentional?

> Looking through testing, I see the following t64 libraries present:

> libaio1t64
> libfyba0t64
> libglibmm-2.68-1t64
> libnetcdf19t64
> libudns0t64
> libczmq4t64 (virtual package; libczmq4 provides this)

Good morning,

I also stumbled over libaio1t64 and looked at the changelog. It is not
part of the transition in that it was simply rebuilt with different
compiler flags and therefore broke the ABI. Instead source code changes
were made to extend the ABI to support usage both from code built with
t64 flags and without.

I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are
only 3 symbols with time_t, and they are not used in the distribution.
Avoid to carry the package rename forever."), but suspect they are
similar.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: xz backdoor

[Andreas Metzler]

On 2024-03-31 Wookey  wrote:
[...]
> e.g. I remember it took me years to realise that I used _my_ public
> key for signing,
[...]

Good morning,

s/public/private/ - $recipient can then use your public key to verify
the sig.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Diane Trout]

Hi Julian,

On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote:
> Lovely to hear from you, and oh wow, that's amazing, thank you!
> 
> I can't speak for anyone else, but I suggest that pushing your
> updates
> to the science-team package would be very sensible; it would be silly
> for someone else to have to redo your work.
> 
> What more is needed for it to be ready for unstable?


The things I think are kind of broken are:

We've got 7.0.0 and upstreams current version is 15.0.2.

the pyarrow 7.0.0 tests fail because it depends on a python test
library that breaks with pytest 8.0. Either I need to disable the
python tests or upgrade to a newer version.

My upgrade didn't go smoothly because uscan found also upstreams debian
watch file which is too loose and matches some other tar balls on their
distribution site.

(Though I don't know why uscan keeps looking for watch files after
finding one in debian/watch)

And you were probably right in that arrow needs to be a team, because I
have no idea how to get other the other languages interfaces packaged.

Oh and I probably need to get the pyarrow installed somewhere, since it
was stopping at the tests I hadn't run into dh_missing errors yet.

Diane

Re: xz backdoor

[Diane Trout]

On Sun, 2024-03-31 at 03:34 +0100, Wookey wrote:
> On 2024-03-30 20:52 +0100, Ansgar  wrote:
> > Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
> > Possibly also TPM modules in computers.
> > 
> > These can usually be used for both OpenPGP and SSH keys.
> 
> Slightly off-topic, but a couple of recent posts have given me the
> same thought:
> 
> Can someone point to good docs on this?  I've had a yubikey for 3/4
> of
> a year now but have not yet worked out how I put my GPG key in it.
> (or
> if it should be another key, or a subkey, or whatever). So I'm not
> actually using it yet.

I've also been thinking I needed to this, and so far this has looked
like the most detailed write up I've found so far.

I haven't followed the advice but I've been working on trying to
understand it.

https://github.com/drduh/YubiKey-Guide

I'd like to know how subkeys interact with signing packages and there's
an two ways of storing ssh keys with yubikeys. This write up describes
one and mentions the other exists.

Diane


signature.asc
Description: This is a digitally signed message part

Re: xz backdoor

[Otto Kekäläinen]

Hi!

On Sat, 30 Mar 2024 at 14:32, Andrey Rakhmatullin  wrote:
> On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote:
> > Another big question for me is whether I should really still
> > package/upload/etc from an unstable machine. It seems that it may be prudent
> > to consider it best practice to work from stable machines where any private
> > keys are involved. For me it's just been so convenient to use unstable
> > because it helps track changes that affect my users by the time it hits
> > stable and also find bugs early that I care about, but perhaps I just need
> > to make that adjustment and find more efficient ways to track unstable
> > (perhaps on additional machines / VMs / etc). Not sure how other DDs think
> > about this, but I'm also curious how they will deal with this, because
> > there's near to no filter between unstable and the outside world, and this
> > is probably not the last time someone will try something like this.
> For me it's simple: if I'm forced to run my tools not on the host but in
> some kind of inconvenient VM/chroot/whatever, I'll just stop contributing.

I am doing all my builds inside a (Podman) container with the sources
loop-mounted. Thus I can use git and visual code editor directly on
sources with full access, but when the build runs, it is fully inside
a container that has no host access nor even network access. To
achieve this I wrote a tool which you might want to check out:
https://salsa.debian.org/otto/debcraft

Re: xz backdoor

[Wookey]

On 2024-03-30 20:52 +0100, Ansgar  wrote:
> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
> Possibly also TPM modules in computers.
> 
> These can usually be used for both OpenPGP and SSH keys.

Slightly off-topic, but a couple of recent posts have given me the
same thought:

Can someone point to good docs on this?  I've had a yubikey for 3/4 of
a year now but have not yet worked out how I put my GPG key in it. (or
if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.

PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.

Basically reasonably idiot-proof docs for people who don't understand
crypto and have no idea what to type.  And a mental model for what
keys (and files) are going where, and why.

e.g. I remember it took me years to realise that I used _my_ public
key for signing, and someone _else's_ public key for encrypting
messges for them. Things made so much more sense then. But it wasn't
at all clear from the docs for DD's to get and use a GPG key back in
2000, so I couldn't send a crypted message for years (because I was
trying to use the wrong key).

I also discovered about 2 years ago (i.e ~20 years after making a key)
that I can change the password on it - it's not immutable! That's
probably something that I should have found out/been told sooner.

I am now aware that I could use subkeys for signing and it would be
more secure, but I don't know how, so I'm not doing it (and this has
been the state for quite a few years now). Did/do I have to make it
differently in the first place, do I do something to the one I already
have (chop it up and keep the bits in different places? sign other
keys with it? something else?) 

Hopefully info at the right level already exists and I just need
pointing at it, but I have tried a couple of times in the past to
understand both yubikey initialisation/use and subkey generation/use
and have failed to make any progress despite reading wiki pages and
man pages and blogs. I just realised that I didn't understand how it
worked or what the tradeoffs were, so couldn't really make sensible
decisions about what I should do. I suspect I'm not the only one who
is quite vague about all this.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: xz backdoor

[Santiago Ruano Rincón]

El 31/03/24 a las 00:53, Christian Kastner escribió:
> On 2024-03-30 22:59, Santiago Ruano Rincón wrote:
> > The backdoor was discovered by someone using the compromised xz-utils *in 
> > their own machines*. So we are lucky we have people eating our own sid 
> > stuff before it becomes part of a stable release.
> 
> The luck was that this particular compromise was discovered, not that it
> happened.

I don't say the opposite.

> 
> I agree that dogfooding is important for discovering quality issues, but
> I think it's a poor argument for discovering security issues, especially
> if it concerns a host which is used for building and signing packages.
> 
> As I mentioned earlier, I think containers are one good way to have
> almost the best of both worlds. One can do anything one could do on
> host, all while being isolated from that host, and with very little
> overhead but also a ton of useful extra features.

I don't see the real benefit.

As others have said, the best solution is to relay on HSW for handling
the cryptographic material.


signature.asc
Description: PGP signature

Re: xz backdoor

[Colin Watson]

On Sun, Mar 31, 2024 at 04:14:13AM +0300, Adrian Bunk wrote:
> The timing of the 5.6.0 release might have been to make it into the 
> upcoming Ubuntu LTS, it didn't miss it by much.

It didn't miss it at all, even.  Ubuntu has rolled it back and is
rebuilding everything that was built using it, but it did make it into
noble-proposed (the current unstable analogue) for some time and noble
(the current testing analogue) briefly.

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

Re: xz backdoor

[Adrian Bunk]

On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote:
>...
> On 2024/03/29 23:38, Russ Allbery wrote:
> > I think the big open question we need to ask now is what exactly the
> > backdoor (or, rather, backdoors; we know there were at least two versions
> > over time) did.
> 
> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine. It seems that it may be prudent
> to consider it best practice to work from stable machines where any private
> keys are involved. For me it's just been so convenient to use unstable
> because it helps track changes that affect my users by the time it hits
> stable and also find bugs early that I care about, but perhaps I just need
> to make that adjustment and find more efficient ways to track unstable
> (perhaps on additional machines / VMs / etc). Not sure how other DDs think
> about this, but I'm also curious how they will deal with this, because
> there's near to no filter between unstable and the outside world, and this
> is probably not the last time someone will try something like this.

I don't think it is such a clear case that stable is more secure than 
unstable.

The uncommon part might be that it was detected so early, and only due 
to a minor visible side effect on performance found by pure luck that a 
better implementation of the exploit might have been able to avoid.

The timing of the 5.6.0 release might have been to make it into the 
upcoming Ubuntu LTS, it didn't miss it by much.

And an intentional backdoor is not necessarily much different from
one caused by a bug:

Heartbleed (CVE-2014-0160) in OpenSSL made it into stable.

The Debian-specific bug that broke the OpenSSL RNG resulting in 
predictable keys (CVE-2008-0166) made it into stable.

There have even been cases where an attacker realized that
a non-security bugfix fixed something that can be exploited.
In such cases unstable might get fixed, but stable not.

Perhaps a case can be made that stable is slightly more secure,
but an intentional backdoor that gets detected early is rather
rare so far.

> -Jonathan

cu
Adrian

Re: xz backdoor

[Christian Kastner]

On 2024-03-30 22:59, Santiago Ruano Rincón wrote:
> The backdoor was discovered by someone using the compromised xz-utils *in 
> their own machines*. So we are lucky we have people eating our own sid stuff 
> before it becomes part of a stable release.

The luck was that this particular compromise was discovered, not that it
happened.

I agree that dogfooding is important for discovering quality issues, but
I think it's a poor argument for discovering security issues, especially
if it concerns a host which is used for building and signing packages.

As I mentioned earlier, I think containers are one good way to have
almost the best of both worlds. One can do anything one could do on
host, all while being isolated from that host, and with very little
overhead but also a ton of useful extra features.

Best,
Christian

Re: xz backdoor

[Pierre-Elliott Bécue]

De : Adrian Bunk 
À : Pierre-Elliott Bécue 
Cc : debian-devel@lists.debian.org
Date : 31 mars 2024 00:25:09
Objet : Re: xz backdoor

> On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
>> ...
>> I'd be happy to have Debian France care about buying and having yubikeys
>> delivered to any DD over the world.
> 
> Including Russia?
> 
> cu
> Adrian
It I leagally can, yes.

-- 
Pierre-Elliott Bécue

Re: xz backdoor

[Roberto C . Sánchez]

On Sun, Mar 31, 2024 at 01:20:39AM +0200, Adrian Bunk wrote:
> On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
> >...
> > I'd be happy to have Debian France care about buying and having yubikeys
> > delivered to any DD over the world.
> 
> Including Russia?
> 
Supporting DDs in Russia would definitely demonstrate a commitment to
geographic diversity.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Validating tarballs against git repositories

[Timo Röhling]

Hi,

* Simon Josefsson  [2024-03-30 12:19]:

Relying on signed git tags is not reliable because git is primarily
SHA1-based which in 2019 cost $45K to do a collission attack for.
FWIW, Gitlab is working on support for SHA 256 hashing [1], and as 
of Git 2.42, the SHA 256 repository format has matured enough that 
backwards incompatible breaks are very unlikely [2].



Cheers
Timo


[1] 
https://about.gitlab.com/blog/2023/08/28/sha256-support-in-gitaly/

[2] https://lore.kernel.org/lkml/xmqqr0nwp8mv.fsf@gitster.g/


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: xz backdoor

[Adrian Bunk]

On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
>...
> I'd be happy to have Debian France care about buying and having yubikeys
> delivered to any DD over the world.

Including Russia?

cu
Adrian

Re: Validating tarballs against git repositories

[Russ Allbery]

Simon Josefsson  writes:
> Russ Allbery  writes:

>> I believe you're talking about two different things.  I think Sean is
>> talking about preimage resistance, which assumes that the known-good
>> repository is trusted, and I believe Simon is talking about
>> manufactured collisions where the attacker controls both the good and
>> the bad repository.

> Right.  I think the latter describes the xz scenario: someone could have
> pushed a maliciously crafted commit with a SHA1 collision commit id, so
> there are two different git repositories with that commit id, and a
> signed git tag on that commit id authenticates both trees, opening up
> for uncertainty about what was intended to be used.  Unless I'm missing
> some detail of how git signed tag verification works that would catch
> this.

This is also my understanding.

>> The dgit and tag2upload design probably (I'd have to think about it
>> some more, ideally while bouncing the problem off of someone else,
>> because I've recycled those brain cells for other things) only needs
>> preimage resistance, but the general case of a malicious upstream may
>> be vulnerable to manufactured collisions.

> It is not completely clear to me: How about if some malicious person
> pushed a commit to salsa, asked a DD to "please review this repository
> and sign a tag to make the upload"?  The DD would presumably sign a
> commit id that authenticate two different git trees, one with the
> exploit and one without it.

Oh, hm, yes, this is a good point.  I had forgotten that tag2upload was
intended to work by pushing a tag to Salsa.  This means an attacker can
potentially race Salsa CI to move that tag to the malicious tree before
the tree is fetched by tag from Salsa, or reuse the signed tag with a
different repository with the same SHA-1.

The first, most obvious step is that one has to make sure that a signed
tag is restricted to a specific package and version and not portable to a
different package and/or version that has the same SHA-1 hash due to
attacker construction.  There are several obvious ways that could be done;
the one that comes immediately to mind is to require the tag message be
the source package name and version number, which is good practice anyway.

I think any remaining issues could be addressed with a fairly simple
modification to the protocol: rather than pushing the signed tag to Salsa,
the DD reviewer should push the signed tag to a separate archive server
similar to that used by dgit today.  As long as the first time the signed
tag leaves the DD's system is in conjunction with a push of the
corresponding reviewed tree to secure project systems, this avoids the
substitution problem.  The tag could then be pushed back to Salsa, either
by the DD or by the service.

This unfortunately means that one couldn't use the Salsa CI service to do
the source package construction, and one has to know about this extra
server.  I think that restriction comes from the fact that we're worried
an attacker may be able to manipulate the Salsa Git repository (through
force pushes and tag replacements, for example), whereas the separate
dedicated archive server can be more restrictive and never allow force
pushes or tag moves, and reject any attempts to push a SHA-1 hash that has
already been seen.

Another possible option would be to prevent force pushes and tag moves in
Salsa, since I think one of those operations would be required to pull off
this attack, but maybe I'm missing someting.  One of the things I'm murky
on is exactly what Git operations are required to substitute the two trees
with identical SHA-1 hashes.  That property is going to break Git in weird
ways, and I'm not sure what that means for one's ability to manipulate a
Git repository over the protocols that Salsa exposes.

Obviously it would be ideal if Git used stronger hashes than SHA-1 for
tags, so that one need worry less about all of this.

Even if my analysis is wrong, I think there are some fairly obvious and
trivial additions to the tag2upload process that would prevent this
attack, such as building a Merkle tree of the reviewed source tree using a
SHA-256 hash and embedding the top hash of that tree in the body of the
signed tag where it can be verified by the archive infrastructure.  That
might be a good idea *anyway*, although it does have the unfortunate side
effect of requiring a local client to produce a correct tag rather than
using standard Git signed tags.  Uploading to Debian currently already
semi-requires a custom local client, so to me this isn't a big deal,
although I think there was some hope to avoid that.

(These variations unfortunately don't help with the upstream problem.)

-- 
Russ Allbery (r...@debian.org)  

Some t64 libraries already in testing; I'm confused

[Julian Gilbey]

My very limited understanding of this major transition was that the
t64 libraries are being held in unstable until (almost) everything is
ready, at which point there will be a coordinated migration into
testing.  But I've now been asked to upgrade something on my testing
machine which pulls in a t64 library.  Has something slipped through
the net, or is this intentional?

Looking through testing, I see the following t64 libraries present:

libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)

Best wishes,

   Julian

Re: xz backdoor

[Leandro Cunha]

Hi,

On Sat, Mar 30, 2024 at 7:00 PM Santiago Ruano Rincón
 wrote:
>
>
>
> Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri  
> escreveu:
> >On Mar 30, Jonathan Carter  wrote:
> >
> >> Another big question for me is whether I should really still
> >> package/upload/etc from an unstable machine. It seems that it may be 
> >> prudent
> >If we do not use unstable for development then who is going to?
> >I think that the real question is whether we should really still use
> >code-signing keys which are not stored in (some kind of) HSM.
> >
>
> The backdoor was discovered by someone using the compromised xz-utils *in 
> their own machines*. So we are lucky we have people eating our own sid stuff 
> before it becomes part of a stable release.
>

You told the truth, sometimes I think it's better to wait a while to
launch very new versions, doing tests beforehand and looking for
problems. But if the person hadn't sent the backdoored version to
unstable, hadn't worried about issues of seconds of performance, in my
opinion it would be quite possible that this would have been in vain
and the person did a great job in mitigating this (I personally I
found very interesting). But on the other hand it caused inconvenience
because I saw in an email here that the processing of the Debian file
is momentarily turned off until it checks what needs to be done.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Re: xz backdoor

[Pierre-Elliott Bécue]

Santiago Ruano Rincón  wrote on 30/03/2024 at 
22:59:43+0100:

> Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri  
> escreveu:
>>On Mar 30, Jonathan Carter  wrote:
>>
>>> Another big question for me is whether I should really still
>>> package/upload/etc from an unstable machine. It seems that it may be prudent
>>If we do not use unstable for development then who is going to?
>>I think that the real question is whether we should really still use 
>>code-signing keys which are not stored in (some kind of) HSM.
>>
>
> The backdoor was discovered by someone using the compromised xz-utils *in 
> their own machines*. So we are lucky we have people eating our own sid stuff 
> before it becomes part of a stable release.

+1 and <3

-- 
PEB


signature.asc
Description: PGP signature

Re: xz backdoor

[Pierre-Elliott Bécue]

Ansgar   wrote on 30/03/2024 at 20:52:29+0100:

> Hi,
>
> On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
>> On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
>> 
>> > I think that the real question is whether we should really still
>> > use 
>> > code-signing keys which are not stored in (some kind of) HSM.
>> What are the options for random DDs for that?
>
> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
> Possibly also TPM modules in computers.
>
> These can usually be used for both OpenPGP and SSH keys.
>
> If someone cannot afford them, I think Debian paying for them is a good
> investment; Debian buying tokens for all project members would also be
> nice, but logistics are probably annoying...
>
> A compromised computer alone is then not enough to get a copy of the
> private key: one would also need an exploit for the hardware token.
> (A compromised computer can still give temporary access to the key when
> it is in use and unlocked; some devices can require pushing a button
> for signing, but of course a compromised computer could claim to sign
> something different than what gets signed and just show a "wrong PIN"
> message to have the user try again.)
>
> If you believe the hardware token to have a backdoor, exploiting it
> might still require physical access to the token.

I'd be happy to have Debian France care about buying and having yubikeys
delivered to any DD over the world.

-- 
PEB
Debian France's Treasurer, happy to spend time to make things safer.


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Adrian Bunk]

On Fri, Mar 29, 2024 at 11:29:01PM -0700, Russ Allbery wrote:
>...
> In other words, we should make sure that breaking the specific tactics
> *this* attacker used truly make the attacker's life harder, as opposed to
> making life harder for Debian packagers while only forcing a one-time,
> minor shift in attacker tactics.  I *think* I'm mostly convinced that
> forcing the attacker into Git commits is a useful partial defense, but I'm
> not sure this is obviously true.
>...

There are also other reasons why using tarballs by default is no longer 
a good option.

In many cases our upstream source is the unsigned tarball Github 
automatically provides for every tag, which invites MITM attacks.

The hash of these tarballs is expected to change over time, which makes 
it harder to reliably verify that the upstream sources we have in the 
archive match what is provided upstream.

cu
Adrian

Re: Validating tarballs against git repositories

[Simon Josefsson]

Russ Allbery  writes:

> Simon Josefsson  writes:
>> Sean Whitton  writes:
>
>>> We did some analysis on the SHA1 vulnerabilities and determined that
>>> they did not meaningfully affect dgit & tag2upload's design.
>
>> Can you share that analysis?  As far as I understand, it is possible for
>> a malicious actor to create a git repository with the same commit id as
>> HEAD, with different historic commits and tree content.  I thought a
>> signed tag is merely a signed reference to a particular commit id.  If
>> that commit id is a SHA1 reference, that opens up for ambiguity given
>> recent (well, 2019) results on SHA1.  Of course, I may be wrong in any
>> of the chain, so would appreciate explanation of how this doesn't work.
>
> I believe you're talking about two different things.  I think Sean is
> talking about preimage resistance, which assumes that the known-good
> repository is trusted, and I believe Simon is talking about manufactured
> collisions where the attacker controls both the good and the bad
> repository.

Right.  I think the latter describes the xz scenario: someone could have
pushed a maliciously crafted commit with a SHA1 collision commit id, so
there are two different git repositories with that commit id, and a
signed git tag on that commit id authenticates both trees, opening up
for uncertainty about what was intended to be used.  Unless I'm missing
some detail of how git signed tag verification works that would catch
this.

> The dgit and tag2upload design probably (I'd have to think about it some
> more, ideally while bouncing the problem off of someone else, because I've
> recycled those brain cells for other things) only needs preimage
> resistance, but the general case of a malicious upstream may be vulnerable
> to manufactured collisions.

It is not completely clear to me: How about if some malicious person
pushed a commit to salsa, asked a DD to "please review this repository
and sign a tag to make the upload"?  The DD would presumably sign a
commit id that authenticate two different git trees, one with the
exploit and one without it.

/Simon


signature.asc
Description: PGP signature

Bug#1068113: ITP: libsmb2 -- SMB2/3 client library

[Joe Mondloch]

ITP: libsmb2 -- SMB2/3 client library
Package: wnpp
Severity: wishlist
Owner: Joe Mondloch 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libsmb2
  Version : 4.0.0
  Upstream Authors: Ronnie Sahlberg 
  URL : https://github.com/sahlberg/libsmb2
* License : LGPL-2.1+
  Description : SMB2/3 client library
 Libsmb2 is a userspace client library for accessing SMB2/SMB3 shares on a
 network. It is high performance and fully async. It supports both zero-copy
 for SMB READ/WRITE commands as well as compounded commands.

Re: xz backdoor

[Santiago Ruano Rincón]

Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri  
escreveu:
>On Mar 30, Jonathan Carter  wrote:
>
>> Another big question for me is whether I should really still
>> package/upload/etc from an unstable machine. It seems that it may be prudent
>If we do not use unstable for development then who is going to?
>I think that the real question is whether we should really still use 
>code-signing keys which are not stored in (some kind of) HSM.
>

The backdoor was discovered by someone using the compromised xz-utils *in their 
own machines*. So we are lucky we have people eating our own sid stuff before 
it becomes part of a stable release.

Re: Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)

[G. Branden Robinson]

Hi Otto,

At 2024-03-30T14:09:46-0700, Otto Kekäläinen wrote:
> While reviewing xz-utils commits I noticed that a bunch of old
> copyright holder names were removed in
> https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78.
> 
> Is this OK to do so?

My opinion is that, _apart from copyright concerns_, an author's
attribution should be removed only if that author's contribution has
been completely removed from the file/work in question.  This is largely
a matter of professional integrity and of avoiding plagiarism.

https://invisible-island.net/personal/copywrongs.html

If someone has rewritten an author's contribution such that none of the
author's "original expression" (a manifestation of human creativity)
remains in the file/work, then it is okay to remove their attribution
and/or copyright notice, and is arguably misleading if you _don't_
remove it.

The untruthful placement or removal of a copyright notices can be a
criminal act in the U.S.[1], but I've never heard of a situation where
someone got into trouble for lazily retaining a notice that was once
applicable to a work, but no longer.  This statute _does_ require
"fraudulent intent", as an element of the crime, a prosecutor is
required to prove it beyond a reasonable doubt to the trier of
fact.[2][3]

Still, candor is a virtue, and, in principle, a false (or no longer
true) claim of copyright could cause problems for an author incorrectly
credited, in the event of some sort of criminal or civil liability
attaching to the work.  The xz backdoor and the mysterious identity of
its perpetrator(s) should underscore this concern.

> Having source code in the public domain means that there is no
> copyright, so no attribution required either?

That's true, but world governments have had great trouble saying "no" to
copyright rentiers for the past century or more, so it can be wise to
retain a public domain dedication notice with the author's name and the
year.

> But if copyright attribution is done, each name should have a year
> next to it at least, right?

Yes, because in theory, software will one day _age_ into the public
domain.  Perhaps infants born today will live to see it happen.

> Is it so that the debian/copyright file is reviewed by ftp-masters
> only for packages in NEW queue, and there is probably no automation in
> place to flag subsequent copyright changes for re-review?

That was my understanding 20 years ago; I can't competently speak to the
status quo.

Regards,
Branden

[1] 
https://www.justice.gov/archives/jm/criminal-resource-manual-1855-protection-copyright-notices-17-usc-506c-and-506d

[2] In practice, over-assertion of copyright would seem to be little
policed; it is common practice for book publishers in the U.S. to
assert flatly impossible copyright notices, asserting a date that
hasn't happened yet.  My anecdotal impression is that over the past
20 years, the month in which one can observe copyright notices dated
in the next calendar year has crept steadily backward.

[3] Of course, most criminal prosecutions in the United States never
proceed to the trial stage,[4] so if you're ever sitting across a
table from a U.S. Attorney, the gap between what is asserted and
what can be proved can be huge.

[4] 
https://www.pewresearch.org/short-reads/2023/06/14/fewer-than-1-of-defendants-in-federal-criminal-cases-were-acquitted-in-2022/


signature.asc
Description: PGP signature

Re: xz backdoor

[Marco d'Itri]

On Mar 30, Christian Kastner  wrote:

> >> Another big question for me is whether I should really still
> >> package/upload/etc from an unstable machine. It seems that it may be 
> >> prudent
> > If we do not use unstable for development then who is going to?
> Are you both talking about unstable hosts, or unstable chroots, or...?
I am talking about our own computers.

Obviously everything is built and rebuilt in unstable chroots.
But I think that we have to eat our dog food.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Adrian Bunk]

On Fri, Mar 29, 2024 at 06:21:27PM -0600, Antonio Russo wrote:
>...
> 1. Move towards allowing, and then favoring, git-tags over source tarballs
>...

git commit IDs, not tags.

Upstream moving git tags does sometimes happen.

Usually for bad-but-not-malicious reasons like "add one more last-minute fix",
but using tags would also invite to manipulation similar to what 
happened with xz at any point after the release.

> Best,
> Antonio Russo

cu
Adrian

Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)

[Otto Kekäläinen]

Hi!

While reviewing xz-utils commits I noticed that a bunch of old
copyright holder names were removed in
https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78.

Is this OK to do so? Having source code in the public domain means
that there is no copyright, so no attribution required either?

But if copyright attribution is done, each name should have a year
next to it at least, right?

Is it so that the debian/copyright file is reviewed by ftp-masters
only for packages in NEW queue, and there is probably no automation in
place to flag subsequent copyright changes for re-review?


Pondering off-topic: I don't expect ftp-masters to have bandwidth to
do manually anything more, so I am specifically keen to understand
what automation is in place. Some improvements can be done in Salsa-CI
for things that the maintainer is likely to be interested in fixing
themselves (e.g. [1], [2]) but the most critical checks for copyright
changes and supply-chain changes related to who is the uploader or
what is the upstream homepage/repository address could perhaps have
some mechanism at ftp-level that requires review/sign-off by
additional Debian Developers, perhaps via a new review tool.

- Otto


[1] https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/342
(missing git tags after upload)
[2] https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/343
(misconfigured upstream git branches)

Re: xz backdoor

[Cyril Brulebois]

Sirius  (2024-03-30):
> I have seen discussion about shifting away from the whole auto(re)conf
> tooling to CMake or Meson with there being a reasonable drawback to
> CMake.  Is that something being discussed within Debian as well?

Talking about alternatives to autotools:
  
https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb81307644efdb58db2c422d9ba7


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Julian Gilbey]

Hi Diane,

On Fri, Mar 29, 2024 at 11:49:07AM -0700, Diane Trout wrote:
> On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote:
> > 
> > 
> > So this is a plea for anyone looking for something really helpful to
> > do: it would be great to have a group of developers finally package
> > this!  There was some initial work done (see the RFP bug report for
> > details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
> > but that is fairly old now.  As Apache Arrow supports numerous
> > languages, it may well benefit from having a group of developers with
> > different areas of expertise to build it.  (Or perhaps it would make
> > more sense to split the upstream source into a collection of
> > different
> > Debian source packages for the different supported languages.  I
> > don't
> > know.)  Unfortunately I don't have the capacity to devote any time to
> > it myself.
> > 
> > Thanks in advance for anyone who can step forward for this!
> 
> I've been maintain dask and anndata and saw that apache arrow was
> getting increasingly popular.
> 
> I took the current science-team preliminary packaging 7.0.0 packaging
> and managed to get it to build through a combination of patches and
> turning off features.
> 
> I even mostly managed to get pyarrow to build. (Though some tests fail
> due to pytest lazy-fixture being abandoned).
> 
> I pushed my current work in progress to.
> 
> https://salsa.debian.org/diane/arrow.git
> 
> Was anyone else planning on working on it or should I push my updates
> to the science-team package?

Lovely to hear from you, and oh wow, that's amazing, thank you!

I can't speak for anyone else, but I suggest that pushing your updates
to the science-team package would be very sensible; it would be silly
for someone else to have to redo your work.

What more is needed for it to be ready for unstable?

Best wishes,

   Julian

Re: Validating tarballs against git repositories

[Robert Edmonds]

Russ Allbery wrote:
> Yes, perhaps it's time to switch to a different build system, although one
> of the reasons I've personally been putting this off is that I do a lot of
> feature probing for library APIs that have changed over time, and I'm not
> sure how one does that in the non-Autoconf build systems.  Meson's Porting
> from Autotools [1] page, for example, doesn't seem to address this use
> case at all.
> 
> [1] https://mesonbuild.com/Porting-from-autotools.html

Have a look at the documentation for the meson "compiler" object [1]. There is a
lot of functionality in meson that has analogs in autoconf that isn't described
in the "Porting from Autotools" document.

[1] https://mesonbuild.com/Reference-manual_returned_compiler.html

-- 
Robert Edmonds
edmo...@debian.org

Re: Validating tarballs against git repositories

[Iustin Pop]

On 2024-03-31 00:58:49, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote:
> > > Now it is time to take a step forward:
> > > 
> > > 1. new upstream release;
> > > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > > 3. the buildd is notified of the new release;
> > > 4. the buildd creates and uploads the non-reviewed-in-practice blobs 
> > > "source
> > > deb" and "binary deb" to unstable.
> > > 
> > > This change would have three advantages:
> > 
> > I think everyone fully agrees this is a good thing, no need to list the
> > advantages.
> > 
> > The problem is that this requies functionality testing to be fully
> > automated via autopkgtest, and moved off the "update changelog, build
> > package, test locally, test some more, upload".
> Do you mean this theoretical workflow will not have a step of the
> maintainer actually looking at the package and running it locally, or
> running any building or linting locally before pushing the changes?
> Then yeah, looking at some questions in the past years I understand that
> some people are already doing that, powered by Salsa CI (I can think of
> several possible reasons for that workflow but it still frustrates me).

Not that it necessarily won't have that step, but how to integrate the
testing into the tag signing/pushing step.

I.e. before moving archive wide to "sign tag + push", there should be a
standard of how this is all tested for a package. Maybe there is and I'm
not aware, my Debian activities are very low key (but I try to keep up
with mailing lists).

> > Give me good Salsa support for autopkgtest + lintian + piuparts, and
> > easy support (so that I just have to toggle one checkbox), and I'm
> > happy. Or even better, integrate all that testing with Salsa (I don't
> > know if it has "CI tests must pass before merging"), and block tagging
> > on the tagged version having been successfully tested.
> AFAIK the currently suggested way of enabling that is putting
> "recipes/debian.yml@salsa-ci-team/pipeline" into "CI/CD configuration
> file" in the salsa settings (no idea where is the page that tells that or
> how to find it even knowing it exists).

Aha, see, this I didn't know. On my list to test once archive is
unblocked and I have time for packaging.

regards,
iustin

Re: xz backdoor

[Christian Kastner]

On 2024-03-30 20:20, Russ Allbery wrote:
> I personally specifically want my workstation to be running unstable, so
> I'm watching to see if that's considered unsafe (either, immediately,
> today, or in theory, in the future).
> 
> If I have to use a stable host, I admit I will be sad.  I've been using
> unstable for my personal client and development (not server, never
> exposing services to the Internet) systems for well over a decade (and,
> before, that, testing systems for as long as I've been working on Debian)
> and for me it's a much nicer experience than using stable.

I've heard many people say that, and I believe them. It might also work
for me if I had more time for Debian ($dayjob is unrelated to FOSS) and
thus more time to react to/report issues I find, but when I come home
from work, I really just want a system where I'm practically never
surprised by a significant change, other than security fixes.

Also, I don't possess the skill to quickly work around transient issues
as you mention below.

> It also lets
> me directly and practically dogfood Debian, which has resulted in a fair
> number of bug reports.

I wish I could do that in general. I try to do so during freezes, for
contributing polish to a release, but otherwise I (1) just place my
faith in upstream's own tests and hope autopkgtests have good coverage
so debci catches things, and (2) I rely on the fact that my work in
containers is also a form of dog-fooding.

For more elaborate projects, I do have complex systems set up based on
various environments. They are trivial to set up, tear down, snapshot,
"fork", etc. And they can be locked down pretty tightly.

And it's actually pretty convenient. Reproducing an issue for some other
release, even of a derivative, often only requires trivial changes to a
Dockerfile, like simply replacing the base image name.

(Actually, now that I think about it, apart from my browser, I probably
spend most of my time in terminals within unstable or experimental
containers, and/or connected to containers running services...)

> (This is an analysis specific to me, not general advice, and relies
> heavily on the fact that I'm very good at working around weird problems
> that transiently arise in unstable.)

Best,
Christian

Re: xz backdoor

[Colin Watson]

On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> I have seen discussion about shifting away from the whole auto(re)conf
> tooling to CMake or Meson with there being a reasonable drawback to CMake.
> Is that something being discussed within Debian as well?

It's not in general something that Debian can unilaterally change.  And
in a number of cases switching build system would be pretty non-trivial.

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

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 08:52:29PM +0100, Ansgar  wrote:
> Hi,
> 
> On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
> > On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
> > 
> > > I think that the real question is whether we should really still
> > > use 
> > > code-signing keys which are not stored in (some kind of) HSM.
> > What are the options for random DDs for that?
> 
> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
> Possibly also TPM modules in computers.
> 
> These can usually be used for both OpenPGP and SSH keys.
Sure (though all the discourse around USB keys in the past 10 years or so
has suggested to me that all of them are bad according to one DD or
other).

> If someone cannot afford them, I think Debian paying for them is a good
> investment; Debian buying tokens for all project members would also be
> nice, 
This was even suggested at least once in the past.

> but logistics are probably annoying...
Exactly.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote:
> > Now it is time to take a step forward:
> > 
> > 1. new upstream release;
> > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > 3. the buildd is notified of the new release;
> > 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
> > deb" and "binary deb" to unstable.
> > 
> > This change would have three advantages:
> 
> I think everyone fully agrees this is a good thing, no need to list the
> advantages.
> 
> The problem is that this requies functionality testing to be fully
> automated via autopkgtest, and moved off the "update changelog, build
> package, test locally, test some more, upload".
Do you mean this theoretical workflow will not have a step of the
maintainer actually looking at the package and running it locally, or
running any building or linting locally before pushing the changes?
Then yeah, looking at some questions in the past years I understand that
some people are already doing that, powered by Salsa CI (I can think of
several possible reasons for that workflow but it still frustrates me).

> Give me good Salsa support for autopkgtest + lintian + piuparts, and
> easy support (so that I just have to toggle one checkbox), and I'm
> happy. Or even better, integrate all that testing with Salsa (I don't
> know if it has "CI tests must pass before merging"), and block tagging
> on the tagged version having been successfully tested.
AFAIK the currently suggested way of enabling that is putting
"recipes/debian.yml@salsa-ci-team/pipeline" into "CI/CD configuration
file" in the salsa settings (no idea where is the page that tells that or
how to find it even knowing it exists).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Ansgar ]

Hi,

On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
> 
> > I think that the real question is whether we should really still
> > use 
> > code-signing keys which are not stored in (some kind of) HSM.
> What are the options for random DDs for that?

Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
Possibly also TPM modules in computers.

These can usually be used for both OpenPGP and SSH keys.

If someone cannot afford them, I think Debian paying for them is a good
investment; Debian buying tokens for all project members would also be
nice, but logistics are probably annoying...

A compromised computer alone is then not enough to get a copy of the
private key: one would also need an exploit for the hardware token.
(A compromised computer can still give temporary access to the key when
it is in use and unlocked; some devices can require pushing a button
for signing, but of course a compromised computer could claim to sign
something different than what gets signed and just show a "wrong PIN"
message to have the user try again.)

If you believe the hardware token to have a backdoor, exploiting it
might still require physical access to the token.

Ansgar

Bug#1068108: ITP: python-pysocks -- Python SOCKS client module

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-pysocks
  Version : 1.7.1
  Upstream Contact: Anorov 
* URL : https://github.com/Anorov/PySocks
* License : BSD
  Programming Lang: Python
  Description : Python SOCKS client module

 PySocks is a Python project that provides an easy way to configure
 and use SOCKS clients. The module is capable of sending traffic through
 SOCKS proxy servers, acting as a direct replacement for the socket module,
 allowing you to configure any socket object by calling the "set_proxy()"
 method, facilitating the routing of network traffic through SOCKS proxies.
 .
 stands out for:
  * Compatibility: Support most features of the SOCKS protocol, including TCP
and, to some extent, UDP, allowing communication with a variety of network
services.
  * Integration: PySocks can be integrated with other Python libraries that
support SOCKS proxies, such as requests.
  * Traffic Anonymization: In projects that require anonymity in network
communication, such as web data scraping or API automation, PySocks can
be integrated to route traffic by hiding the client's IP address.

 Note: This package is a required dependency for the TeraBoxUtility
 ITP package: #1067395

Re: Validating tarballs against git repositories

[Iustin Pop]

On 2024-03-30 11:47:56, Luca Boccassi wrote:
> On Sat, 30 Mar 2024 at 09:57, Iustin Pop  wrote:
> >
> > On 2024-03-30 08:02:04, Gioele Barabucci wrote:
> > > Now it is time to take a step forward:
> > >
> > > 1. new upstream release;
> > > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > > 3. the buildd is notified of the new release;
> > > 4. the buildd creates and uploads the non-reviewed-in-practice blobs 
> > > "source
> > > deb" and "binary deb" to unstable.
> > >
> > > This change would have three advantages:
> >
> > I think everyone fully agrees this is a good thing, no need to list the
> > advantages.
> >
> > The problem is that this requies functionality testing to be fully
> > automated via autopkgtest, and moved off the "update changelog, build
> > package, test locally, test some more, upload".
> >
> > Give me good Salsa support for autopkgtest + lintian + piuparts, and
> > easy support (so that I just have to toggle one checkbox), and I'm
> > happy. Or even better, integrate all that testing with Salsa (I don't
> > know if it has "CI tests must pass before merging"), and block tagging
> > on the tagged version having been successfully tested.
> 
> This is all already implemented by Salsa CI? You just need to include
> the yml and enable the CI in the settings

I will be the first to admit I'm not up to date on latest Salsa news,
but see, what you mention  - "include the yml" - is exactly what I don't
want.

If maintainers need to include a yaml file, it means it can vary between
projects, which means it can either have bugs or be hijacked. In my
view, there should be no freedom here, just one setting - "enable
tag2upload with automated autopkg testing", and all packages would
behave mostly the same way. But there are 2KiB single-binary packages as
well as 2GB 25 binary packages, so maybe this is too wide scope.

I just learned about tag2upload, need to look into that.

(I'm still processing this whole story, and I fear the fallout/impact
in terms of how development is regarded will be extremely high.)

regards,
iustin

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
> On Mar 30, Jonathan Carter  wrote:
> 
> > Another big question for me is whether I should really still
> > package/upload/etc from an unstable machine. It seems that it may be prudent
> If we do not use unstable for development then who is going to?
Yup.

> I think that the real question is whether we should really still use 
> code-signing keys which are not stored in (some kind of) HSM.
What are the options for random DDs for that?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote:
> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine. It seems that it may be prudent
> to consider it best practice to work from stable machines where any private
> keys are involved. For me it's just been so convenient to use unstable
> because it helps track changes that affect my users by the time it hits
> stable and also find bugs early that I care about, but perhaps I just need
> to make that adjustment and find more efficient ways to track unstable
> (perhaps on additional machines / VMs / etc). Not sure how other DDs think
> about this, but I'm also curious how they will deal with this, because
> there's near to no filter between unstable and the outside world, and this
> is probably not the last time someone will try something like this.
For me it's simple: if I'm forced to run my tools not on the host but in
some kind of inconvenient VM/chroot/whatever, I'll just stop contributing.
I'm not even discussing any of that proper Debian setups with keys on
separate airgapped machines, that's just not funny.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Russ Allbery]

Christian Kastner  writes:

> This is both out of convenience (I want my workstation to be based on
> stable) and precisely because of the afforded isolation.

I personally specifically want my workstation to be running unstable, so
I'm watching to see if that's considered unsafe (either, immediately,
today, or in theory, in the future).

If I have to use a stable host, I admit I will be sad.  I've been using
unstable for my personal client and development (not server, never
exposing services to the Internet) systems for well over a decade (and,
before, that, testing systems for as long as I've been working on Debian)
and for me it's a much nicer experience than using stable.  It also lets
me directly and practically dogfood Debian, which has resulted in a fair
number of bug reports.

(This is an analysis specific to me, not general advice, and relies
heavily on the fact that I'm very good at working around weird problems
that transiently arise in unstable.)

But this does come with a security risk because it means a compromised
package could compromise my system much faster than if I were using
testing or, certainly, stable.  That's not a security trade-off that I can
responsibly make entirely for myself, since it affects people who are
using Debian as well.  So I don't get to have the final decision here.

-- 
Russ Allbery (r...@debian.org)  

Re: xz backdoor

[Christian Kastner]

On 2024-03-30 17:00, Marco d'Itri wrote:
> On Mar 30, Jonathan Carter  wrote:
> 
>> Another big question for me is whether I should really still
>> package/upload/etc from an unstable machine. It seems that it may be prudent
> If we do not use unstable for development then who is going to?

Are you both talking about unstable hosts, or unstable chroots, or...?

I do all my development on a stable host, within rootless podman
containers which are trivial to set up. I run final sbuilds and
autopkgtests in QEMU VMs, also trivial to set up.

This is both out of convenience (I want my workstation to be based on
stable) and precisely because of the afforded isolation.

Best,
Christian

Re: Validating tarballs against git repositories

[Russ Allbery]

Jeremy Stanley  writes:
> On 2024-03-29 23:29:01 -0700 (-0700), Russ Allbery wrote:
> [...]
>> if the Git repository is somewhere other than GitHub, the
>> malicious possibilities are even broader.
> [...]

> I would not be so quick to make the same leap of faith. GitHub is
> not itself open source, nor is it transparently operated. It's a
> proprietary commercial service, with all the trust challenges that
> represents. Long, long before XZ was a twinkle in anyone's eye,
> malicious actors were already regularly getting their agents hired
> onto development teams to compromise commercial software. Just look
> at the Juniper VPN backdoor debacle for a fairly well-documented
> example (but there's strong evidence this practice dates back well
> before free/libre open source software even, at least to the 1970s).

This is a valid point: let me instead say that the malicious possibilities
are *different*.  All of your points about GitHub are valid, but the
counterexample I had in mind is one where the malicious upstream runs the
entire Git hosting architecture themselves and can make completely
arbitrary changes to the Git repository freely.  I don't think we know
everything that is possible to do in that situation.  I think it would be
difficult (not impossible, but difficult) to get into that position at
GitHub, whereas it is commonplace among self-hosted projects.

-- 
Russ Allbery (r...@debian.org)  

Re: xz backdoor

[Sirius]

In days of yore (Fri, 29 Mar 2024), Russ Allbery thus quoth: 
> Russ Allbery  writes:
> > Sirius  writes:
> 
> >> This is quite actively discussed on Fedora lists.
> >> https://www.openwall.com/lists/oss-security/2024/
> >> https://www.openwall.com/lists/oss-security/2024/03/29/4
> 
> >> Worth taking a look if action need to be taken on Debian.
> 
> > The version of xz-utils was reverted to 5.4.5 in unstable yesterday by
> > the security team and migrated to testing today.  Anyone running an
> > unstable or testing system should urgently upgrade.
> 
> I think the big open question we need to ask now is what exactly the
> backdoor (or, rather, backdoors; we know there were at least two versions
> over time) did.  If they only target sshd, that's one thing, and we have a
> bound on systems possibly affected.  But liblzma is linked directly or
> indirectly into all sorts of things such as, to give an obvious example,
> apt-get.  A lot of Debian developers use unstable or testing systems.  If
> the exploit was also exfiltrating key material, backdooring systems that
> didn't use sshd, etc., we have a lot more cleanup to do.
> 
> I think this question can only be answered with reverse-engineering of the
> backdoors, and I personally don't have the skills to do that.

>From what I understand and have read, there is someone that will take a
look at reverse-engineering the .o and figure out what it did. The fact
the exploit looked for /usr/bin/sshd as argv[0] suggests it was targeted
at providing a backdoor into systems via just sshd. To what end, I guess
we will find out. Botnet would be the least worrisome IMHO.

A striking aspect is that this exploit was slow and methodical. This was
no ordinary script-kiddie doing things for giggles. I do wonder what will
shake out of this, but this level of patience and planning does raise
questions.

As you point out, the compression libraries are a weak link. I would think
the authentication and crypto libraries are as well. In this instance,
maybe both Debian and Fedora can breathe a sigh of relief that things got
caught when they did and that the remediation is not man-months or
man-years worth of effort. That said, someone plowing this amount of time
into planting just the one exploit may have other projects sized up where
they can try again.

I have seen discussion about shifting away from the whole auto(re)conf
tooling to CMake or Meson with there being a reasonable drawback to CMake.
Is that something being discussed within Debian as well?


-- 
Kind regards,

/S

Re: Validating tarballs against git repositories

[Jeremy Stanley]

On 2024-03-29 23:29:01 -0700 (-0700), Russ Allbery wrote:
[...]
> if the Git repository is somewhere other than GitHub, the
> malicious possibilities are even broader.
[...]

I would not be so quick to make the same leap of faith. GitHub is
not itself open source, nor is it transparently operated. It's a
proprietary commercial service, with all the trust challenges that
represents. Long, long before XZ was a twinkle in anyone's eye,
malicious actors were already regularly getting their agents hired
onto development teams to compromise commercial software. Just look
at the Juniper VPN backdoor debacle for a fairly well-documented
example (but there's strong evidence this practice dates back well
before free/libre open source software even, at least to the 1970s).

If anything, compromising an open project or transparent service is
probably considerably harder, these sorts of people thrive in the
comfort of shadows that the proprietary software world offers them,
and (thankfully) struggle in the open, like with the rather quick
identification and public response demonstrated in this case. I
would be quite surprised by similarly rapid or open discussion from
a proprietary service who discovered a saboteur in their ranks.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: xz backdoor

[Marco d'Itri]

On Mar 30, Jonathan Carter  wrote:

> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine. It seems that it may be prudent
If we do not use unstable for development then who is going to?
I think that the real question is whether we should really still use 
code-signing keys which are not stored in (some kind of) HSM.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Russ Allbery]

Simon Josefsson  writes:
> Sean Whitton  writes:

>> We did some analysis on the SHA1 vulnerabilities and determined that
>> they did not meaningfully affect dgit & tag2upload's design.

> Can you share that analysis?  As far as I understand, it is possible for
> a malicious actor to create a git repository with the same commit id as
> HEAD, with different historic commits and tree content.  I thought a
> signed tag is merely a signed reference to a particular commit id.  If
> that commit id is a SHA1 reference, that opens up for ambiguity given
> recent (well, 2019) results on SHA1.  Of course, I may be wrong in any
> of the chain, so would appreciate explanation of how this doesn't work.

I believe you're talking about two different things.  I think Sean is
talking about preimage resistance, which assumes that the known-good
repository is trusted, and I believe Simon is talking about manufactured
collisions where the attacker controls both the good and the bad
repository.

The dgit and tag2upload design probably (I'd have to think about it some
more, ideally while bouncing the problem off of someone else, because I've
recycled those brain cells for other things) only needs preimage
resistance, but the general case of a malicious upstream may be vulnerable
to manufactured collisions.

(So far as I know, preimage attacks against *MD5* are still infeasible,
let alone against SHA-1.)

-- 
Russ Allbery (r...@debian.org)  

Re: Validating tarballs against git repositories

[Russ Allbery]

Ingo Jürgensmann  writes:

> This reminds me of https://xkcd.com/2347/ - and I think that’s getting a
> more common threat vector for FLOSS: pick up some random lib that is
> widely used, insert some malicious code and have fun. Then also imagine
> stuff that automates builds in other ways like docker containers, Ruby,
> Rust, pip that pull stuff from the network and installs it without
> further checks.

> I hope (and am confident) that Debian as a project will react
> accordingly to prevent this happening again.

Debian has precisely the same problem.  We have more work to do than we
possibly can do with the resources we have, there is some funding but not
a lot of funding so most of the work is hobby work stolen from scarce free
time, and we're under a lot of pressure to encourage and incorporate the
work of new maintainers.

And 99% of the time trusting the people who step up to help works out
great.

The hardest part about defending against social engineering is that it
doesn't attack attack the weakness of a community.  It attacks its
*strengths*: trust, collaboration, and mutual assistance.

-- 
Russ Allbery (r...@debian.org)  

Re: Validating tarballs against git repositories

[Russ Allbery]

Luca Boccassi  writes:

> In the end, massaged tarballs were needed to avoid rerunning autoconfery
> on twelve thousands different proprietary and non-proprietary Unix
> variants, back in the day. In 2024, we do dh_autoreconf by default so
> it's all moot anyway.

This is true from Debian's perspective.  This is much less obviously true
from upstream's perspective, and there are some advantages to aligning
with upstream about what constitutes the release artifact.

> When using Meson/CMake/home-grown makefiles there's no meaningful
> difference on average, although I'm sure there are corner cases and
> exceptions here and there.

Yes, perhaps it's time to switch to a different build system, although one
of the reasons I've personally been putting this off is that I do a lot of
feature probing for library APIs that have changed over time, and I'm not
sure how one does that in the non-Autoconf build systems.  Meson's Porting
from Autotools [1] page, for example, doesn't seem to address this use
case at all.

[1] https://mesonbuild.com/Porting-from-autotools.html

Maybe the answer is "you should give up on portability to older systems as
the cost of having a cleaner build system," and that's not an entirely
unreasonable thing to say, but that's going to be a hard sell for a lot of
upstreams that care immensely about this.

-- 
Russ Allbery (r...@debian.org)  

Re: Validating tarballs against git repositories

[Simon Josefsson]

Jonathan Carter  writes:

> On 2024/03/30 11:05, Simon Josefsson wrote:
>>> 1. Move towards allowing, and then favoring, git-tags over source tarballs
>>
>> Some people have suggested this before -- and I have considered adopting
>> that approach myself, but one thing that is often overlooked is that
>> building from git usually increase the Build-Depends quite a lot
>> compared to building from tarball
>
> How in the world do you jump to that conclusion?

By comparing the set of tools required to build from git with the tools
installed by Build-Depends* for common projects.  I'm thinking of
projects like coreutils, wget, libidn2, gnutls, gzip, etc.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Gioele Barabucci]

On 30/03/24 14:08, Jonathan Carter wrote:

On 2024/03/30 12:43, Sean Whitton wrote:

On 2024-03-30 08:02:04, Gioele Barabucci wrote:

Now it is time to take a step forward:

1. new upstream release;
2. the DD/DM merges the upstream release VCS into the Debian VCS;
3. the buildd is notified of the new release;
4. the buildd creates and uploads the non-reviewed-in-practice blobs 
"source

deb" and "binary deb" to unstable.

This change would have three advantages:

I think everyone fully agrees this is a good thing, no need to list the
advantages.

 >

It is also already fully implemented as tag2upload, and is merely as yet
undeployed, for social reasons.


My understanding is that DSA aren't quite comfortable with it, since it 
would need to archive GPG signing key (or a keypair trusted by DAK)?


Don't the buildd already work like in similar way?

The source deb is signed by the DD, the buildd checks the signature of 
the source deb, then builds and signs the binary debs.


In the future the tag is signed by the DD, the buildd checks the 
signature of the tag, then builds and signs the source deb and the 
binary debs.


--
Gioele Barabucci

Re: Validating tarballs against git repositories

[Gioele Barabucci]

On 30/03/24 13:38, Jonathan Carter wrote:

On 2024/03/30 11:05, Simon Josefsson wrote:
1. Move towards allowing, and then favoring, git-tags over source 
tarballs

 >

Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends quite a lot
compared to building from tarball


How in the world do you jump to that conclusion?


Usually it's due to thing like precompiled documentation: 
{man,info}pages, HTML pages.


To generate these files you usually need texinfo, groff, pandoc, sphinx, 
etc. All big packages with plenty of runtime and build-time dependencies.


But as I said, for cases like arch rebootstraps,  can remove the 
need to bootstrap a long (and often circular) chain of dependencies.


Regards,

--
Gioele Barabucci

Re: Validating tarballs against git repositories

[Antonio Russo]

There are many important and useful things here, but I want to address
this one point:

On 2024-03-30 00:29, Russ Allbery wrote:
> Antonio Russo  writes:
> 
>> If that's the case, could make those files at packaging time, analogous
>> to the DFSG-exclude stripping process?
> 
> If I have followed this all correctly, I believe that in this case the
> exploit is not in a build artifact.  It's in a very opaque source artifact
> that is different in the release tarball from the Git archive.  Assuming
> that I have that right, stripping build artifacts wouldn't have done
> anything about this exploit, but comparing Git and release tarballs would
> have.
> 
> I think you're here anticipating a *different* exploit that would be
> carried in build artifacts that Debian didn't remove and reconstruct, and
> that we want to remove those from our upstream source archives in order to
> ensure that we can't accidentally do that.

In this case, as Guillem walks through in a later email, build-to-host.m4
would be generated by autotools under different circumstances (not Debian
today, because of differences in versions).

I therefore consider that file a build artifact, perhaps incorrectly given
Simone's comment that autoreconf cannot be used to reliably re-bootstrap all
of these files.

I was (before Simone's point) arguing to ALWAYS re-bootstrap it all, or at
least always rebootstrap on a Debian machine.  A prerequisite to this, more
generally then, is that we can always rebootstrap from auditable source.

I appreciate that, unless that binary process happens reproducibly, that
just shifts the trustee to a different person, and doesn't actually address
this kind of carefully-orchestrated attack. I also appreciate the Ken
Thompson "trusting trust" nightmare scenario makes the compiler another
major issue.

What I'm hoping for is more limited: assume our existing infrastructure is
sound, but develop hygiene and tooling that prevents accepting binary and
build-artifact Trojans into Debian.

Best,
Antonio

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Validating tarballs against git repositories

[Lisandro Damián Nicanor Pérez Meyer]

On Sat, 30 Mar 2024 at 10:16, Guillem Jover  wrote:
[snip]

This:

> I'm personally not a fan of pristine-tar, and my impression is that it
> is falling out of favor in various corners and big teams within the
> project. And then I'm also not a fan either for mixing packaging with
> upstream git history. The non-native packages I maintain only contain
> debian/ directories, which to me have the superior properties (but not
> tooling), including in a situation like this. I'll expand on this later.

And this:

> I think the biggest issue is that we are pretty much based on a model
> that relies on trusting upstreams, for code, for license and copyright
> compliance, etc. We tend to assume upstreams (and us!) can make
> mistakes, but that in general they are not working against us.
>
> When confronted with a known hostile (and not necessarily malicious)
> upstream the only winning game is not to play. If we do not even know
> the upstream is hostile and/or malicious that seems like a losing
> prospect to me. There are so many ways such upstream can slip stuff
> through in this model that this gets really nasty really quickly.
>
> Don't get me wrong, I think we can/should modify our processes and
> tooling somehow to at last try tot deter this path as much as possible,
> but it still seems to go counter to our model, and seems like a losing
> prospect. (You could have an upstream that tries to overwhelm you with
> sheer amount of commits for example. In this case they even included
> the bulk of the backdoor in git, and in the end I guess I don't see
> much difference between smuggling something through git or a tarball.)
>
> And, coming back to the Debian side of things. To me the most
> important part is that we might be able to close a bit this door with
> upstream, but what about this happening within Debian? I think we have
> discussed in the past, what would happen if someone tried this kind of
> long term attack on the project, and my feeling is that we have kind
> of shrugged it off as either "it would take too much effort so it's
> implausible" or "if they want to do it we are lost anyway" but perhaps
> I'm misremembering.
>
> Related to this, dgit has been brought up as the solution to this, but
> in my mind this incident reinforces my view that precisely storing
> more upstream stuff in git is the opposite of what we'd want, and
> makes reviewing even harder, given that in our context we are on a
> permanent fork against upstream, and if you include merge commits and
> similar, there's lots of places to hide stuff. In contrast storing
> only the packaging bits (debian/ dir alone) like pretty much every
> other downstream is doing with their packaging bits, makes for an
> obviously more manageable thing to review and not get drown into,
> more so if we have to consider that next time perhaps the long-game
> gets played within Debian. :(
>
> (An additional bonus of only keeping debian/ directories is that it
> would make it possible to checkout all Debian packaging locally. :)

Are the most insightful things I've read so far, both on the social
and technical side of things.

I will add that comparing autogenerated files in big/huge projects is
something utterly complicated. Could take days of work. On the other
hand big/huge projects tend to have much more eyes, but things can
always go wrong.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Validating tarballs against git repositories

[Simon Josefsson]

Sean Whitton  writes:

> Hello,
>
> On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote:
>
>> Relying on signed git tags is not reliable because git is primarily
>> SHA1-based which in 2019 cost $45K to do a collission attack for.
>
> We did some analysis on the SHA1 vulnerabilities and determined that
> they did not meaningfully affect dgit & tag2upload's design.

Can you share that analysis?  As far as I understand, it is possible for
a malicious actor to create a git repository with the same commit id as
HEAD, with different historic commits and tree content.  I thought a
signed tag is merely a signed reference to a particular commit id.  If
that commit id is a SHA1 reference, that opens up for ambiguity given
recent (well, 2019) results on SHA1.  Of course, I may be wrong in any
of the chain, so would appreciate explanation of how this doesn't work.

/Simon


signature.asc
Description: PGP signature

Bug#1068094: RFH: sbcl -- Common Lisp compiler and development system

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: s...@packages.debian.org, debian-devel@lists.debian.org, 
debian-emac...@lists.debian.org
Control: affects -1 + src:sbcl

I request assistance with maintaining SBCL in Debian.

It is the most popular Free Software compiler for Common Lisp.
So, most anyone who is interested in both Debian and Common Lisp is likely
interested in SBCL, too.

The upstream project is stable but seems relatively often to introduce changes
that break our packaging scripts.
Possibly there should be an attempt made to simplify how we do things.

This would be good for a new contributor to Debian who is otherwise
experienced with bootstrapping compilers / development environments.
You definitely don't need to be a Debian Developer to help.

The package description is:
 SBCL is a development environment for the ANSI Common Lisp language.
 It provides a native-code compiler and an integrated debugger, as well
 as all the features in the ANSI specification.
 .
 SBCL also contains other extensions to the ANSI specification, including
 a foreign-function interface, a pseudo-server API, user-extensible
 stream functionality, a Meta-Object Protocol, and an ability to run
 external processes.
 .
 To browse SBCL source definitions with development environments,
 install the sbcl-source package. For documentation on SBCL's usage
 and internals, the package sbcl-doc is provided.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068093: ITP: python-cotengrust -- Fast contraction ordering primitives for tensor networks

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com

* Package name: python-cotengrust
  Version : 0.1.1
  Upstream Contact: Johnnie Gray 
* URL : https://github.com/jcmgray/cotengrust
* License : AGPL-3
  Programming Lang: Python, Rust
  Description : Fast contraction ordering primitives for tensor networks

`cotengrust` provides fast rust implementations of contraction
 ordering primitives for tensor networks or einsum expressions.
 The two main functions are `optimize_optimal(inputs, output, size_dict,
 **kwargs)` and `optimize_greedy(inputs, output, size_dict, **kwargs)`.
 Planning to maintain it under DPT, need sponsor.

Re: Validating tarballs against git repositories

[Guillem Jover]

Hi!

On Fri, 2024-03-29 at 23:53:20 -0600, Antonio Russo wrote:
> On 2024-03-29 22:41, Guillem Jover wrote:
> > On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote:
> >> Had tooling existed in Debian to automatically validate this faithful
> >> reproduction, we might not have been exposed to this issue.
> > 
> > Given that the autogenerated stuff is not present in the git tree,
> > a diff between tarball and git would always generate tons of delta,
> > so this would not have helped.
> 
> I may not have been clear, but I'm suggesting scrubbing all the
> autogenerated stuff, and comparing that against a similarly scrubbed
> git tag contents.  (But you explain that this is problematic.)

Yes, the point here is how we determine what is autogenerated stuff
when confronted with a malicious upstream, so the problem again is
that if you need to verify everything then you might easily get
overwhelmed by sheer amount of autogenerated output. But see below.

> >> Having done this myself, it has been my experience that many partial
> >> build artifacts are captured in source tarballs that are not otherwise
> >> maintained in the git repository.  For instance, in zfs (which I have
> >> contributed to in the past), many automake files are regenerated.
> >> (I do not believe that specific package is vulnerable to an attack
> >> on the autoconf/automake files, since the debian package calls the
> >> upstream tooling to regenerate those files.)
> 
> (Hopefully the above clears up that I at least have some superficial
> awareness of the build artifacts showing up in the release tarball!)

(Sorry, I guess my reply might have sounded patronizing? I noticed later
on that you explicitly mentioned this, but thought that would be clear
then when reading the whole mail, thought about adding a note to the
earlier text, but considered it unnecessary. Should have probably added
it anyway. :)

> >> 1. Move towards allowing, and then favoring, git-tags over source tarballs
> > 
> > I assume you mean git archives out of git tags? Otherwise how do you
> > go from git-tag to a source package in your mind?
> 
> I'm not wed to any specific mechanism, but I'd be content with that.  I'd
> be most happy DD-signed tags that were certified dfsg, policy compliant
> (i.e., lacking build artifacts), and equivalent to scrubbed upstream source.
> (and more on that later, building on what you say).
> 
> Many repositories today already do things close to this with pristine-tar,
> so this seems to me a direction where the tooling already exists.
> 
> I'll add that, if we drop the desire for a signed archive, and instead
> require a signed git-tag (from which we can generate a source tar on
> demand, as you suggest), we can drop the pristine-tar requirement.  If we
> are less progressive, but move to exclusively with Debian-regenerated
> .tar files, we can probably avoid many of the frustrating edge cases that
> pristine-tar still struggles with.

I'm personally not a fan of pristine-tar, and my impression is that it
is falling out of favor in various corners and big teams within the
project. And then I'm also not a fan either for mixing packaging with
upstream git history. The non-native packages I maintain only contain
debian/ directories, which to me have the superior properties (but not
tooling), including in a situation like this. I'll expand on this later.

I've been thinking and, perhaps the only thing we'd need, is to include
either a file or a field in some file that refers to the upstream commit
we think the tarball is derived from. We also have fields that contain
the upstream VCS repo. Then we could also have tooling that could perform
such checks, independently from how we transport and pack our sources.

> >> 2. Require upstream-built artifacts be removed (instead, generate these
> >>ab-initio during build)
> > 
> > The problem here is that the .m4 file to hook into the build system was
> > named like one shipped by gnulib (so less suspicious), but xz-utils does
> > not use gnulib, and thus the autotools machinery does not know anything
> > about it, so even the «autoreconf -f -i» done by debhelper via
> > dh-autoreconf, would not regenerate it.
> 
> The way I see it, there are two options in handling a buildable package:
> 
> 1. That file would have been considered a build artifact, consequently
> removed and then regenerated.  No backdoor.
>
> 2. The file would not have been scrubbed, and a difference between the
> git version and the released tar version would have been noticed.
> Backdoor found.
> 
> Either of these is, in my mind, dramatically better than what happened.

Sure, but that relies on knowing for certain what is and what is not
autogenerated for 1), and to not be able to get drown in autogenerated
output for 2) so that this cannot be easily missed, and for autoreconf
to do what we expect! Also important is when this would be done, only
on initial packaging, on every build? Because 1) has the bad property
that it 

Re: Validating tarballs against git repositories

[Jonathan Carter]

Hi Sean

On 2024/03/30 12:43, Sean Whitton wrote:

On 2024-03-30 08:02:04, Gioele Barabucci wrote:

Now it is time to take a step forward:

1. new upstream release;
2. the DD/DM merges the upstream release VCS into the Debian VCS;
3. the buildd is notified of the new release;
4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
deb" and "binary deb" to unstable.

This change would have three advantages:

I think everyone fully agrees this is a good thing, no need to list the
advantages.

>

It is also already fully implemented as tag2upload, and is merely as yet
undeployed, for social reasons.


My understanding is that DSA aren't quite comfortable with it, since it 
would need to archive GPG signing key (or a keypair trusted by DAK)?


I did enjoy the tag2upload talk that was given earlier this year at 
miniDebConf Campridge:


https://peertube.debian.social/w/pav68XBWdurWzfTYvDgWRM

One of the things I like most about it is that it doesn't break any 
existing workflow or technical implementation. And it seems like 
something most people would reasonably want to see implemented.


So I think it boils down to finding some constructive way to engage with 
ftpmasters to find a solution that they are content with, because 
without that, nothing is going to happen. I'm not 100% sure that I would 
classify that as a social reason, DSA/ftpmaster is careful out of necessity.


Any chance we can convince both ftpmaster members and tag2upload team to 
join at DebConf24 in Busan so that an attempt can be made to hash this 
out in person? I'm not sure everyone involved will be motivated enough 
to join a sprint just to work on this, but it tends to work so much 
better when people work on problems together in person rather than 
emails where people want to reply thoughtfully and then end up taking 
weeks to do so.


I think it's not so much a question of *if* the Debian would ever switch 
to a git-based workflow, but *when*. And tag2upload's opt-in nature 
provides a great bridge to that future, there's clearly been a lot of 
good thought put into it, and there's really no alternative that even 
comes close in either design or being so close to being ready for 
implementation. However, I think it can only happen if you get all the 
right people in the same room to address the remaining concerns.


-Jonathan

Re: Validating tarballs against git repositories

[Bastian Blank]

On Sat, Mar 30, 2024 at 01:30:07PM +0100, Jan-Benedict Glaw wrote:
> On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci  wrote:
> > On 30/03/24 01:21, Antonio Russo wrote:
> > > 3. Have tooling that automatically checks the sanitized sources against
> > > the development RCSs.
> > git-buildpackage and pristine-tar can be used for that.
> Would be nice if pristine-tar's data file would be reproducible,
> too...

Use pristine-lfs.  Or just generate via "git archive".

Bastian

-- 
It is undignified for a woman to play servant to a man who is not hers.
-- Spock, "Amok Time", stardate 3372.7

Re: Validating tarballs against git repositories

[G. Branden Robinson]

At 2024-03-30T14:38:03+0200, Jonathan Carter wrote:
> On 2024/03/30 11:05, Simon Josefsson wrote:
> > > 1. Move towards allowing, and then favoring, git-tags over source tarballs
> >
> > Some people have suggested this before -- and I have considered
> > adopting that approach myself, but one thing that is often
> > overlooked is that building from git usually increase the
> > Build-Depends quite a lot compared to building from tarball
> 
> How in the world do you jump to that conclusion?

I don't know about "usually", but "often" seems fair enough; it's true
of groff.

https://git.savannah.gnu.org/cgit/groff.git/tree/INSTALL.REPO?h=1.23.0#n15

Regards,
Branden


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Jonathan Carter]

On 2024/03/30 11:05, Simon Josefsson wrote:

1. Move towards allowing, and then favoring, git-tags over source tarballs

>

Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends quite a lot
compared to building from tarball


How in the world do you jump to that conclusion?

-Jonathan

Re: Validating tarballs against git repositories

[Jan-Benedict Glaw]

On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci  wrote:
> On 30/03/24 01:21, Antonio Russo wrote:
> > 3. Have tooling that automatically checks the sanitized sources against
> > the development RCSs.
> 
> git-buildpackage and pristine-tar can be used for that.

Would be nice if pristine-tar's data file would be reproducible,
too...

MfG, JBG

-- 


signature.asc
Description: PGP signature

Accepted sphinx-testing 1.0.1-0.3 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 13:06:48 +0100
Source: sphinx-testing
Architecture: source
Version: 1.0.1-0.3
Distribution: unstable
Urgency: medium
Maintainer: Kouhei Maeda 
Changed-By: Alexandre Detiste 
Changes:
 sphinx-testing (1.0.1-0.3) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Remove python3-mock & python3-six dependencies.
Checksums-Sha1:
 6b41b1bfa6071de079706dca7bf922d43c6f7619 1983 sphinx-testing_1.0.1-0.3.dsc
 a0c49ce6979a16486ed389f87f743db9029025a9 4380 
sphinx-testing_1.0.1-0.3.debian.tar.xz
 cc567efeee8aac5c366970c59669583210e21d37 8544 
sphinx-testing_1.0.1-0.3_source.buildinfo
Checksums-Sha256:
 3ed3d233e0ba6bd4449c212d4a87973e8a6b4d412582455e4bc1816dd68d04af 1983 
sphinx-testing_1.0.1-0.3.dsc
 3f4d5a507864954ab92b59e5e29f94fe78d2220043737e6539ae469bd6e30951 4380 
sphinx-testing_1.0.1-0.3.debian.tar.xz
 1e9b3a5c68da0a30e22c81a3c4d6ebfd13d1c6e7329f2e7af9b166afe8daa644 8544 
sphinx-testing_1.0.1-0.3_source.buildinfo
Files:
 612d6606747cc66dd3e3c318ee201aed 1983 python optional 
sphinx-testing_1.0.1-0.3.dsc
 3ef8e4936ab143bd76e2f67582e37873 4380 python optional 
sphinx-testing_1.0.1-0.3.debian.tar.xz
 dabcfcd1a0b465fa4172d8bb214e8dfc 8544 python optional 
sphinx-testing_1.0.1-0.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEj23hBDd/OxHnQXSHMfMURUShdBoFAmYIAJERHHRjaGV0QGRl
Ymlhbi5vcmcACgkQMfMURUShdBo+bQ/+IN15uQcQxldedlOIjLKOo7zPj6vAzZMq
/ujWIES5NfSBYj2icKrSqnwuB6IDiVd3DA+R9OMxQDpMrzsya04GpqbAOeKLMDbz
7siDIBzUNG6kHeSAe5TR3ipMJutCyH2OAP21jfU7TJXPfqjvFwkvmCUf/apiGDld
kORk1Jgd/DRPkIi3vh9h/yZ7rLvStIMdDudn5BUof6jSel2PHR1G0Wu/H022IH8k
xMaj9XxD1ftroL6wCBLNMXcQPWQ7ybJrjfoRj+we41+oG1vEUGLVgGprAcNOFvCq
nnFQWzgjEU3qqy5tgzeuZjf9YbjWFgoOFHGR7/zKHVoCHfALsW7T+8br9B4GAlRp
4zdFnH3smEPVOKZvdaeUMMubuR+IDTiPthiJyuSuLb8kMYqum+6iQZPggCakXD30
i8ogroMSuHEgDzSEvDvfRpmb7GeLZmazRcxM/ag3I1ldt65oqaMaJJzNDF4RyMtL
SGzz7TfO5E7Llw+0pQQAuTShjk+SOW2a9jT1zFPDoGrnsiInyuPLxUTipMYQcr8M
K70Yu9L+ZdORxKaSvRIPTedW7cdNl9q/ejpj/gLi++Q0YTXGw6IuOYwHcn2SZr3D
/mvjBmJiHYszJBt+puKdNrdK8aFR4g0cceMo6+TDJONAE63hsRMkzB9STuHz+ygZ
8p4V4+5dZNI=
=uJ3e
-END PGP SIGNATURE-



pgp16SCnc6NWi.pgp
Description: PGP signature

Accepted libreoffice 4:24.2.2-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 09:30:30 +
Source: libreoffice
Architecture: source
Version: 4:24.2.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian LibreOffice Maintainers 
Changed-By: Rene Engelhard 
Changes:
 libreoffice (4:24.2.2-2) unstable; urgency=medium
 .
   * debian/patches/split-sdbc-firebird-mariadb.diff: create extra
 {mysqlc,firebird_sdbc}.xcd add as for evoab. Otherwise configuration
 parts of it ends up (or not in indep builds) in libreoffice-commons
 main.xcd
   * debian/rules:
 - install new {mysqlc,firebird_sdbc}.xcd into the respective
   packages
 - build-depend on liborcus-dev (>> 0.19.2-3+b1) as for libxmlsec1-dev
   * debian/libreoffice-sdbc-{mysql,firebird}.ucf: add
   * debian/control.in: add Breaks: -sdbc-{mysql,firebird} (<< 4:24.2.2-2)
 to libreoffice-common
Checksums-Sha1:
 4498b0cd87d27ed867ac16478e8f67ab53ccc0bf 36777 libreoffice_24.2.2-2.dsc
 c7815c55e790821d62e1acd3e992c74dd8aa86e0 24872724 
libreoffice_24.2.2-2.debian.tar.xz
 6e667dd5fe8bce73ea70bf8fd832f5e22851c283 26032 
libreoffice_24.2.2-2_source.buildinfo
Checksums-Sha256:
 5ca53593374a7ac2c7e777511370e880a5bf886c28fc7b44993b3d6a12712f75 36777 
libreoffice_24.2.2-2.dsc
 4aa17f56b443db2ba06e65bfae5454f172353814faf06a6ba39bc2743ea19398 24872724 
libreoffice_24.2.2-2.debian.tar.xz
 9ef764bb8a36f8d441b70f4fe69bc46137106f2d1967d329e78d2140d5b53c86 26032 
libreoffice_24.2.2-2_source.buildinfo
Files:
 acd9adf4a906237338f39efb07b850f5 36777 editors optional 
libreoffice_24.2.2-2.dsc
 534506993eed165f01da2bbe67f9294f 24872724 editors optional 
libreoffice_24.2.2-2.debian.tar.xz
 572cb0aad797d2b3040773a336652982 26032 editors optional 
libreoffice_24.2.2-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEE4S3qRnUGcM+pYIAdCqBFcdA+PnAFAmYH6yoQHHJlbmVAZGVi
aWFuLm9yZwAKCRAKoEVx0D4+cOJdEADDFhrQT3bnYTC/zMumRASbJU2UIe86W9dO
vc44Sl30EsUxjw+X0/ql3aJMnWjGso4Cmq9s5yXi4ARjGlztRuVShADPA7jNFo65
kSEC3rMVByWWghhNpMWim1t7A92klv1b6ANUIAeLWFEeBRky6J2kyoMnjpykle34
idNZvu6yLES/5kx0sGDBXmGKNtOKYL3LaR3NdSUhVis3sj461wz7f5bNI8Rv8nGQ
Xp1W+wgvLBXwHvAiRCy0GvMN4x6J9iG74oFmOzs5Bkzve3BLZN/JN8pjUQXDxkbY
VrQ0YJqbSoKubfHatlz+3IC4ZjRP56O/wcCqavatjNHwoJ1VToaFy07LPN+n1MVi
rQasMrMPNpMzVBiLObbpTTLFZMn9Qn2Fak/jchnSHIKvE+ca7UKyUMp5RFH0Uiqj
Vde/ufgXFB+K89Aj0FJVbiVmQ+l2Ns/JIf5HWGbqs1jatzOfR3aTfBda7L+OifmO
VYyLIF++xXD280CinJhdt1culj9cHHVdd03EZRCQxPdkr09D+nYXq27RX6Jx0sWh
ftHO26MrBjA1wNzsSlO5EjCa6ZlRMT6hAgVhNfirTKw4rFiY/zWa3AeFrCyQt3Uw
EnnuH9uYZlVZsCf9EFFb5LXZ8gEfqdnjG4lqy1veTFWcks26p9iHGcKYf/SErgpW
9aByIwjjrQ==
=s7g6
-END PGP SIGNATURE-



pgp77EhH5eb4p.pgp
Description: PGP signature

Re: Validating tarballs against git repositories

[Sean Whitton]

Hello,

On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote:

> Relying on signed git tags is not reliable because git is primarily
> SHA1-based which in 2019 cost $45K to do a collission attack for.

We did some analysis on the SHA1 vulnerabilities and determined that
they did not meaningfully affect dgit & tag2upload's design.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Luca Boccassi]

On Sat, 30 Mar 2024 at 06:29, Russ Allbery  wrote:
>
> Antonio Russo  writes:
>
> > The way I see it, there are two options in handling a buildable package:
>
> > 1. That file would have been considered a build artifact, consequently
> > removed and then regenerated.  No backdoor.
>
> > 2. The file would not have been scrubbed, and a difference between the
> > git version and the released tar version would have been noticed.
> > Backdoor found.
>
> > Either of these is, in my mind, dramatically better than what happened.
>
> I think the point that you're assuming (probably because you quite
> reasonably think it's too obvious to need to be stated, but I'm not sure
> it's that obvious to everyone) is that malicious code injected via a
> commit is significantly easier to detect than malicious code that is only
> in the release tarball.
>
> This is not *always* correct; it really depends on how many eyes are on
> the upstream repository and how complex or unreadable the code upstream
> writes normally is.  (For example, I am far from confident that I can
> eyeball the difference between valid and malicious procmail-style C code
> or random M4 files.)  I think it's clearly at least *sometimes* correct,
> though, so I'm sympathetic, particularly given that it's already Debian
> practice to regenerate the build system files anyway.
>
> In other words, we should make sure that breaking the specific tactics
> *this* attacker used truly make the attacker's life harder, as opposed to
> making life harder for Debian packagers while only forcing a one-time,
> minor shift in attacker tactics.  I *think* I'm mostly convinced that
> forcing the attacker into Git commits is a useful partial defense, but I'm
> not sure this is obviously true.

While it's of course true that avoiding massaged tarballs as orig.tar
is not a panacea, and that obfuscated malicious code can and is
checked in git, I am pretty sure it is undeniable that having
everything tracked in git makes it _easier_ to audit and investigate.
Not perfect, not fool-proof, but easier, compared to manually diffing
tarballs. And given we are talking about malicious actors using
subterfuge to attack us, I think we could use all the help we can get,
even if there's no perfect solution.

In the end, massaged tarballs were needed to avoid rerunning
autoconfery on twelve thousands different proprietary and
non-proprietary Unix variants, back in the day. In 2024, we do
dh_autoreconf by default so it's all moot anyway. When using
Meson/CMake/home-grown makefiles there's no meaningful difference on
average, although I'm sure there are corner cases and exceptions here
and there.

Accepted daemontools 1:0.76-10 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 11:50:59 +0100
Source: daemontools
Architecture: source
Version: 1:0.76-10
Distribution: unstable
Urgency: medium
Maintainer: Joost van Baal-Ilić 
Changed-By: Jan Mojžíš 
Closes: 1066623
Changes:
 daemontools (1:0.76-10) unstable; urgency=medium
 .
   * d/p/0005-fix-ftbfs.patch add, fix FTBFS (Closes: 1066623)
   * d/gbp.conf: add [pull] track-missing = True
   * d/copyright: bump my copyright year
Checksums-Sha1:
 8f45f4ffdf16467f341c96cf36021b2ddf87c884 2078 daemontools_0.76-10.dsc
 07e06c517da980b81b2746fbfe0a0931d96cfb65 20568 
daemontools_0.76-10.debian.tar.xz
 07f342d49d14cfadd7fcfe9c954863c1dbcfcafe 6336 
daemontools_0.76-10_source.buildinfo
Checksums-Sha256:
 76d0f63b847563cb82ac0f13fc0b6a17297f972c8cdec11954f84289fe06a27d 2078 
daemontools_0.76-10.dsc
 fbdc7c7768ee6e5b4d72abd0418664aa17c0ad247aaf983acc9ebbac11e9ec60 20568 
daemontools_0.76-10.debian.tar.xz
 665e43143d530ec5fad520913b990fbe0dbb028d15b1da15642f4088443bf2b2 6336 
daemontools_0.76-10_source.buildinfo
Files:
 493aa17910e709f203cf474517467f78 2078 admin optional daemontools_0.76-10.dsc
 4c2dd3cd71c764013ac6f45aea77a962 20568 admin optional 
daemontools_0.76-10.debian.tar.xz
 80db1abc425bbc2487d471caf819c91b 6336 admin optional 
daemontools_0.76-10_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEE0Aiwwj2EeeRrn8uQRdpRdJaTn/kFAmYH+UgVHGphbi5tb2p6
aXNAZ21haWwuY29tAAoJEEXaUXSWk5/5pkEP/3jHpqOp+RdNOFhBF0SzXgl5kbYm
7BKpTkjWa+CYuM9EiBkRWnTF9a4fSTDHKe/TgvGPMbQkQk/cpdKdef2uLzJK/mkj
kuOSP1tS1BNqsLMZr8Xod09baFt5KVHWa0zs9F4oxXOppKeAzc9sB0HKOh4JyOmk
L7uzmFkmPx7FO5PDe9NoKJf676XY/IKJSy/ocDKMBOe4RGEwKR6umZ8FwhJmgWBT
f2orac8mNex/Eh36e6+vG2HJyyvuEGlbURmBQzkxtcFcN/y7NpvwP+nN7ASNRt/S
gazOyJYmQEKIjilRAMwOSEJARtLXIl2+DGc40BNw/gqpOUSqErR/UGcclzCpwwhc
XQOjssTrDOz38alT+4wTNCaUpI7sUK6Vhm7y+nvK7Sb96b6VRqEy9IITtsj6NRM0
ImaO5jBYyEVlgwVrX5hUJCYRvZbGv7Ed41fB5inL4A5qVY7gil7uClRMlg2ZsTg3
thS/Ozp8VryTQBfMTb3bzWix+4brgEqEu5OFfMWSPVyn+PPKfBI2ZzZPXO6NITBz
fzQvZe65INHvwA42CVRT7tB+KeJhkeoXRVfKtIldzdCG8e13jIbYepvBM8qKPIie
wM+BsOCBNlb9LKjM+qJVNpUoQu6jxqB8+jfZ1OahA3/6sRawtH4X4+URFXYLemip
gSumuTRw/Y47TxDH
=E9kn
-END PGP SIGNATURE-



pgp5K0z5HEJvl.pgp
Description: PGP signature

Accepted cockpit-podman 86-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 12:29:42 +0100
Source: cockpit-podman
Architecture: source
Version: 86-1
Distribution: unstable
Urgency: medium
Maintainer: Martin Pitt 
Changed-By: Martin Pitt 
Changes:
 cockpit-podman (86-1) unstable; urgency=medium
 .
   * New upstream bug fix release.
Checksums-Sha1:
 42c3dfebf9bd96c6e60594e426b8319cd2183c61 1992 cockpit-podman_86-1.dsc
 604d9603b579e881e7520afe724361a8c9523950 1307196 cockpit-podman_86.orig.tar.xz
 408000b5a12e7d59d84959badad36b5e29aa856f 4572 cockpit-podman_86-1.debian.tar.xz
 68afc4ee0860b04815b30e064296cabf0f16fda7 5565 
cockpit-podman_86-1_source.buildinfo
Checksums-Sha256:
 ef67c21fff8dbc927fac6095d5ad4786178e26a3084211d55b70663e046f8399 1992 
cockpit-podman_86-1.dsc
 99327e951ed2acc2f405b4b01af5f423112c04d59be3f7fb02e8ebfa34d4a4a0 1307196 
cockpit-podman_86.orig.tar.xz
 08695be840d020bb4ed567189c2ac06a4dfa6fce61adff88c1f99e88b0967292 4572 
cockpit-podman_86-1.debian.tar.xz
 5699c211e9f14692b4ab199ffc6319c064c373c43da1ca3b8de82eb4c64c1849 5565 
cockpit-podman_86-1_source.buildinfo
Files:
 561e0325324effc937ce3d71d07d5251 1992 admin optional cockpit-podman_86-1.dsc
 8488f694519d94562d4eaa4599e2bcaa 1307196 admin optional 
cockpit-podman_86.orig.tar.xz
 c800e3189bab4c789890b60b0d28b43f 4572 admin optional 
cockpit-podman_86-1.debian.tar.xz
 ff2d33e027ecbd925c43e83c3a724f26 5565 admin optional 
cockpit-podman_86-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbEuHi35jHxYFV8PN7nvd5LhrVxMFAmYH97gACgkQ7nvd5Lhr
VxPgExAAto00mAfSYucCCKcXwrxMOgYOVatOIra/Y/Z3M8Mp93cSWMNER5HjSt3G
UXI+P7YNj/otrXHU/jH7MdXUk1IWC9tjhxzo7TAhhAOHXtU0wkOnsIlr4Mujs5Zr
LMvsRQs1Kb/cPmO04a3AHPLrTbBSpZqiPWg4PQgM5aGa2eEE3gFAGeleOhkoSfyR
rh3OQOdmuIqSiE6o0xfnXG1d0U01R/VA2auVaHntARH6wPo0gmxiTFAe/YF8knXG
ysT6dF+T7wYEeYy8c34I5y+JcYFHNOyqqp0tnkij8zElLyMoviKjKjUOWvwowMmK
929oq9EI+cyNW5wLnaOSPoVlBLnSdIEXHJIJvYfETKENkYmI3AIbJytedh5dXh2q
7K8CLoaCpNRc+EwvsGdXV6z1/dqxwQiDHzTVN1hULh0QJNyY5KvKDolpagTcUY6O
182J4O7JtM3ksFtdwczrPIgJ8gtoIJZl9DfiQVMqcTYbes6NltEhAsKEGf0RyG9/
mZo10SlkkVNrM42GCCmqCcD5EeVIsPnhl6zNU+MO2Rbt8gDWAr6/SI/yn/7HbsIx
komwwSUpE1yMAsA9bjXaxDmuS+d30vsbi7uiqmBLYnNtRU+0Mg1lwWvo1YOu98g7
+YDrCA5KNaCEEIadd/yobJoyzVFD0LcqXun5Nc6ax7W6QBzK3+4=
=lxwS
-END PGP SIGNATURE-



pgpM8BYQXq0pP.pgp
Description: PGP signature

Accepted cockpit-machines 310-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 12:31:43 +0100
Source: cockpit-machines
Architecture: source
Version: 310-1
Distribution: unstable
Urgency: medium
Maintainer: Utopia Maintenance Team 

Changed-By: Martin Pitt 
Changes:
 cockpit-machines (310-1) unstable; urgency=medium
 .
   * New upstream bug fix release.
Checksums-Sha1:
 0ba32130a5af6dcfacd9cff1824b710ab7d2fb26 2144 cockpit-machines_310-1.dsc
 e9d642c98aecd9307fc39d122563899afbf7056e 2034164 
cockpit-machines_310.orig.tar.xz
 1f2fa7cb42b25d7ec7a346b40e8a4b00b62d7b4f 6300 
cockpit-machines_310-1.debian.tar.xz
 7683250ed19e38cf40805e891c1c6107f65c5243 5577 
cockpit-machines_310-1_source.buildinfo
Checksums-Sha256:
 386b318b8e4100b5291148176c5c5246f6e1f4363b4ac7ec236d8bd8a2bee270 2144 
cockpit-machines_310-1.dsc
 30c347436be136c5f543f29be6fb14ee6ed89185e852b9d204bb61be517208b6 2034164 
cockpit-machines_310.orig.tar.xz
 30b13c79f356099fe1e323808837e158d3a34aaef458d7dfacc66584c4d03f4b 6300 
cockpit-machines_310-1.debian.tar.xz
 bf91dc5b9e7241c1b6ffb6b0b2792fe80ff0cd44c1445fe996d35cad78b03db4 5577 
cockpit-machines_310-1_source.buildinfo
Files:
 76b890f15330a17109b7045b540c589b 2144 admin optional cockpit-machines_310-1.dsc
 712e066e1e1be504788be292ec3810a9 2034164 admin optional 
cockpit-machines_310.orig.tar.xz
 74e5567ea9573c8895982505a2cb47ac 6300 admin optional 
cockpit-machines_310-1.debian.tar.xz
 22ba4f57060b2ff556583496263adb75 5577 admin optional 
cockpit-machines_310-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbEuHi35jHxYFV8PN7nvd5LhrVxMFAmYH+DcACgkQ7nvd5Lhr
VxPu2Q//Xk779FzPXImZyVB9Xe9GWKBBCCgMluo6YvROFSto8/HnmFbQ6r77gxOg
JPUvjCxQeSPGlJsyZfh2KpeYGuFRs+ZBCKv3SNIIXYR2nNfT2lAHxX9+X45mGdrW
xESzhLV5qKRgsIhPXvt6p05C1ZB+VygC8fDc2SV4P7+aCwIz4xUf2jisevBvejXX
JYYpfNwuLXY7sgRqG0kivijpoFwqMpbaa30VVbuQCURQbws5j6TDMfz98Bts6COe
SuJz63meNFHAQe/4TkH77VkPEHpeAA/fJNGA8rz0irBv84dawaKcfmBQjyJwieTC
JRW3YLS06557Z84cZRlRiIujlsSRTl4IZMcvVO8ajz26O7orkbm/cdLPtOo8KGUg
mLN7v6ldgyTOQBR8Nh/Y6SXrgr+yj8E9FNl9MMbWF2VGNl3mBHYWco2JxsICrFkI
kB4+U/lV883WezWsXfbLFfvnZZM23qoideD49G0/nTE6tNGF6ngDVJXO1xk7uUYG
ksz/617do2aYi5JdS0i+wuDBA2TuekQshR1mQNfKdhoouE6TCnCaH2tHA20PqFsJ
qBGUzGpW2Mt7AWnhO8llTICVXoIzkmvg4xkBHL6MyGHeRra7fAjxqrFGWsU3u0GU
cZo7Or9JNz0zkBCGjVfvwHBpqZ/0EXpbky1+ldhkVRSUiEDb56s=
=hd6j
-END PGP SIGNATURE-



pgp7yVffPxUl1.pgp
Description: PGP signature

Accepted cockpit 314-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 12:25:09 +0100
Source: cockpit
Architecture: source
Version: 314-1
Distribution: unstable
Urgency: medium
Maintainer: Utopia Maintenance Team 

Changed-By: Martin Pitt 
Changes:
 cockpit (314-1) unstable; urgency=medium
 .
   * New upstream security fix release:
 - Diagnostic reports: Fix command injection vulnerability with crafted
   report names [CVE-2024-2947]
 - Storage: Improvements to read-only encrypted filesystems
Checksums-Sha1:
 57550b0d25397059635b32ad02ee84fced1a692c 3185 cockpit_314-1.dsc
 4d240e1a1292c8513b175004b263d94f84bb0cb4 14509292 cockpit_314.orig.tar.xz
 bc8e28da835dc7faa0e2d5afe28fee361beccee2 20892 cockpit_314-1.debian.tar.xz
 7754d9ff7eb4cf5017a2122772f62cc2b9fdee0c 7685 cockpit_314-1_source.buildinfo
Checksums-Sha256:
 1dc05832b5ccd1713e287e5badaa07a32178c990255ffd2cbda5cbe1fdf29120 3185 
cockpit_314-1.dsc
 a92955e73ec3d9569db74675268baaec963c07f6db12c1a64bb57a25b1eb0f6a 14509292 
cockpit_314.orig.tar.xz
 547c948246f8d69fe91bc56d5fd111d2015afedadb33093f9db003f218ada930 20892 
cockpit_314-1.debian.tar.xz
 8f0014f9924de3e74911ce6e9c3f6d2721e506f3815a7719fec47222bda7da0b 7685 
cockpit_314-1_source.buildinfo
Files:
 2dd221abbed956bb15093fa0cbe43fde 3185 admin optional cockpit_314-1.dsc
 7111e36937c9f371b07e9d933a4067e4 14509292 admin optional 
cockpit_314.orig.tar.xz
 d49f1fead7c5f6402b714b36bf436b64 20892 admin optional 
cockpit_314-1.debian.tar.xz
 1c7a83f4b337d3d1a4c313b95606ff30 7685 admin optional 
cockpit_314-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbEuHi35jHxYFV8PN7nvd5LhrVxMFAmYH9usACgkQ7nvd5Lhr
VxMu5BAAmp/4XTEa39dpWIYeJSGPRIJPVHmvpCdqAB3t+5nDYiodibQK1FXjwaxz
U/cKzOkLUUNyEf5OWuyG3YIQSSlMGiKh7Uy6pm+EYDUB2ss9Pwqdrw3Np9kj9E7p
jiB0AdY2mJNkOvOBVZ01g/4dOFp8vlD35lS5V3NefbPMDsHuPSfXfSQ5blPlU+3B
5OlffN2K7mEL0xLH1vMYIo8g0plAArOhXQIR0p/hi2bbhcyMf03rJav2J2Ol9IDI
g7tkEhdzGNfRO/A1T3ZG/4s3/NPbHkoj3KpDEIH3xAdUteAYBCtDmJZriSMo5U5U
APqfTiRa1b44MvEpkke1z8PaUtKyMqBYyDskcpduyuf8i5r+zs2u6OLoz3wUA259
9m3yWCUt0qumrri80xN/KCuRCmefTulNc2W7588CxtWk/k8JRj0sQdlaNDk3NVZZ
G1CngdstzA9RhPTwgRdqHPu4YhT5lKroVSNQQWBDdrfOWbcZLVVWmR0aCgaP+V5j
l6eeZa/KDak1T0EQuj7Db3IdXNSgzUqjPzG1p2YAk6pOdUd1+sDfwtyCQStfLhUM
/AyxVuXiX7Tmoxw6M+HEAFHAAo8ctJad441Pll9jqFbD2lN9BKYeY5o8rK32yDZO
6QFfzk6sRpN7GR9ihmPZHLIVpmU3yDwGEQmBzR2+GkumL7Memhc=
=jkwI
-END PGP SIGNATURE-



pgpVNqAfYxxZJ.pgp
Description: PGP signature

Re: Validating tarballs against git repositories

[Luca Boccassi]

On Sat, 30 Mar 2024 at 09:57, Iustin Pop  wrote:
>
> On 2024-03-30 08:02:04, Gioele Barabucci wrote:
> > Now it is time to take a step forward:
> >
> > 1. new upstream release;
> > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > 3. the buildd is notified of the new release;
> > 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
> > deb" and "binary deb" to unstable.
> >
> > This change would have three advantages:
>
> I think everyone fully agrees this is a good thing, no need to list the
> advantages.
>
> The problem is that this requies functionality testing to be fully
> automated via autopkgtest, and moved off the "update changelog, build
> package, test locally, test some more, upload".
>
> Give me good Salsa support for autopkgtest + lintian + piuparts, and
> easy support (so that I just have to toggle one checkbox), and I'm
> happy. Or even better, integrate all that testing with Salsa (I don't
> know if it has "CI tests must pass before merging"), and block tagging
> on the tagged version having been successfully tested.

This is all already implemented by Salsa CI? You just need to include
the yml and enable the CI in the settings

Re: xz backdoor

[Pierre-Elliott Bécue]

Jonathan Carter  wrote on 30/03/2024 at 09:49:33+0100:

> Hi Russ
>
> On 2024/03/29 23:38, Russ Allbery wrote:
>> I think the big open question we need to ask now is what exactly the
>> backdoor (or, rather, backdoors; we know there were at least two versions
>> over time) did.
>
> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine. It seems that it may be
> prudent to consider it best practice to work from stable machines
> where any private keys are involved. For me it's just been so
> convenient to use unstable because it helps track changes that affect
> my users by the time it hits stable and also find bugs early that I
> care about, but perhaps I just need to make that adjustment and find
> more efficient ways to track unstable (perhaps on additional machines
> / VMs / etc). Not sure how other DDs think about this, but I'm also
> curious how they will deal with this, because there's near to no
> filter between unstable and the outside world, and this is probably
> not the last time someone will try something like this.

Needing to be able to see how things I package go on when reaching
unstable, I tend to work on testing/unstable laptops.

I took some measures to reduce the risks of a permanent compromission:

 - My main GPG key is not on the machine (it's on a specific device I
   use only on my workstation);
 - My subkeys are rotated periodically (two years-ish I'd say);
 - They are on a YubiKey;
 - My laptop/workstations are hardened (firewall, usbguard,
   non-necessary services are removed, …).

This of course is not enough to mitigate a full-fledged compromission,
but I believe we need to live with some status quo. This time we found
out the compromission "fast". But it could also have reached stable-bpo
or, like other non-voluntary flaws, lived in software for multiple
years.

While I'm fine changing the way I do things, I am not sure that there is
any reasonable extent we could reach in order to prevent such
situations.

-- 
PEB


signature.asc
Description: PGP signature

Accepted llvm-defaults 0.59~exp2 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 30 Mar 2024 12:19:55 +0100
Source: llvm-defaults
Built-For-Profiles: noudeb
Architecture: source
Version: 0.59~exp2
Distribution: experimental
Urgency: medium
Maintainer: LLVM Packaging Team 
Changed-By: Gianfranco Costamagna 
Changes:
 llvm-defaults (0.59~exp2) experimental; urgency=medium
 .
   [ chenli ]
   * Fix the default selection on loong64
 .
   [ Gianfranco Costamagna ]
   * Merge loong64 0.58~exp2 upload
   * Merge entries for 0.58 and 0.58.1 from sid
 (no renaming necesary for llvm-18)
Checksums-Sha1:
 b1eb23ce339bb82b025af686686b782fdea793a4 3618 llvm-defaults_0.59~exp2.dsc
 bc239e1df304f062e40685848af4ad16342909cc 15420 llvm-defaults_0.59~exp2.tar.xz
 ff6ecc1d644a5990e526ea0bf65a6bc6bbcbaca7 8359 
llvm-defaults_0.59~exp2_source.buildinfo
Checksums-Sha256:
 187cc06778cf0cf27a3c8ef335c520356ab92bf3cd11535fe992d34b27bb92a7 3618 
llvm-defaults_0.59~exp2.dsc
 16eb8e98d7ddd88d0a5b0f7ebbf463ae83c3d0c92e8c3739ba115b92da8b201b 15420 
llvm-defaults_0.59~exp2.tar.xz
 a55e8e23ddd19f9701c119f3c416cae2960e848af9c78745f07dcf402b8ab926 8359 
llvm-defaults_0.59~exp2_source.buildinfo
Files:
 acb22ae8479da7f6824e918212132e0e 3618 devel optional 
llvm-defaults_0.59~exp2.dsc
 820918f217ff0d94686a7f57e7654ed9 15420 devel optional 
llvm-defaults_0.59~exp2.tar.xz
 34e108e3acf1b0c422e36c1ededea6b1 8359 devel optional 
llvm-defaults_0.59~exp2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAmYH9rAACgkQ808JdE6f
XdmwvxAAmzF7QcDdeAAV1YxkPGT4HdTPGBC7siJFpoP4sneOxjvvzWTXB6aD9a3S
C+OjaYJhTAEpMdkODVEq8ThQzbq9NeGF/3Nrn62ol7/wlERmon/BALw7z47CUY8z
/CE+z7rVEJLTN919+b2UwhvbIlND6Bhv9LBkCpzuZM0hA26Qlusa2xyNdnIiHGLO
EICI2thCw2aZJCo8rlqmKfKO5XUp911jVid1IHPJK+8NFNLHblQigsWT/ILG5RaR
gTS2mdabNUtfiquUQ6mAdjzq+3OYDnu0YPAueFhtZOcH1XmS6hdRKUCsSrhsRUVv
y1/G+R0SO6lkoIm5G4r/Q0YMj0HDkpTv/msQCAcCi8GMBdParTNsv5zuttbOem7Q
o4JQQib1Ntb1IT9fICTZ2FRnnj1Hl4SHmTrHX607SdJlcKGvulCbed4LFxxgUNyv
s1O7hLXZaAgZRfhqSta6Bg9YBr5lkQnS8LYhSdXtbL5ig2DHuKfEhbkwAl6EABXg
Mhgb6VdzQumdwtU+eOG1KfQAmk6GhjTsVmogctX/2YjWBrqOQDscJXnDO+uRC1Nc
MV2PmISa8Y71u8GKQLgw93agWP4rK89FO+Xo75cA9Aej199w2hRj80sB+SiIr0Kz
TeHAIUXmAv6eHLOaalq4II3trNdUTLky0k3cdEFX4diiR0Kjq7I=
=0TId
-END PGP SIGNATURE-



pgpxcNAm4QxDs.pgp
Description: PGP signature

Re: xz backdoor

[Henrique de Moraes Holschuh]

On Sat, Mar 30, 2024, at 05:49, Jonathan Carter wrote:

> Another big question for me is whether I should really still 
> package/upload/etc from an unstable machine. It seems that it may be 

I have been using stable or old stable + pbuilder for this.  Test runs of the 
results might need a VM though, when stable + container is not enough.

-- 
  Henrique de Moraes Holschuh 

Re: Validating tarballs against git repositories

[Simon Josefsson]

Gioele Barabucci  writes:

> Just as an example, bootstrapping coreutils currently requires
> bootstrapping at least 68 other packages, including libx11-6 [1]. If 
> coreutils supported  [2], the transitive closure of its
> Build-Depends would be reduced to 20 packages, most of which in 
> build-essential.
>
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=coreutils=amd64=9.4-3.1=1710441056=1
> [2] https://bugs.debian.org/1057136

Coreutils in Debian uses upstream tarballs and does not do a full
bootstrap build.  It does autoreconf instead of ./bootstrap.  So the
dependencies above is not the entire bootstrapping story to build
coreutils from git compared to building from tarballs.

It would help if upstreams would publish PGP-signed 'git-archive'-style
tarballs, including content from git submodules in them.

Relying on signed git tags is not reliable because git is primarily
SHA1-based which in 2019 cost $45K to do a collission attack for.

/Simon


signature.asc
Description: PGP signature

Accepted llvm-defaults 0.58.1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 11:27:13 +0100
Source: llvm-defaults
Built-For-Profiles: noudeb
Architecture: source
Version: 0.58.1
Distribution: unstable
Urgency: medium
Maintainer: LLVM Packaging Team 
Changed-By: Matthias Klose 
Changes:
 llvm-defaults (0.58.1) unstable; urgency=medium
 .
   * Fix t64 dependency for libomp5.
Checksums-Sha1:
 e6f6858f75957fd5a1ef04f76c64433e3fa9dc34 3615 llvm-defaults_0.58.1.dsc
 d423be71a2d4ab9db63ee6c500c16c08ab3bbd6e 15020 llvm-defaults_0.58.1.tar.xz
 fa3170c48804747acc269a8162199dabf9280c36 4334 
llvm-defaults_0.58.1_source.buildinfo
Checksums-Sha256:
 adda353a9060b48de64a2acfb75ffa74da62a1d7c227f7ea7b9dfeb153014bee 3615 
llvm-defaults_0.58.1.dsc
 58c8b95caebcaa2986176d17e6a03e7bf33820622ad2bf29666455bb223f8b1a 15020 
llvm-defaults_0.58.1.tar.xz
 b11f3c5eb4c63b439c56f2a97ecc5c8e0298b90dd46f47b322b80a55d2016e2d 4334 
llvm-defaults_0.58.1_source.buildinfo
Files:
 14da2437bc2d995b182955eca6f084f5 3615 devel optional llvm-defaults_0.58.1.dsc
 e104eae220e6db2a5427cb20448b6e57 15020 devel optional 
llvm-defaults_0.58.1.tar.xz
 e54e6130571acf4e8e398ec974101689 4334 devel optional 
llvm-defaults_0.58.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAmYH6UIQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9ftHD/92e4X+LAZi+v/Tpt070l9ONjtnsEmctsbp
4vP8cxrXFZ1tTI/r2mfdvptgSpew6K34Se1TCweqGHjoF6JJWHeM/18Tov6oes/t
iZHB0IhinSIW84bK8Gz5LigAsrnswxbiOOcFgygf/zY7BYc96LAh3v3OYDTDF4+Q
Z2NRKz8IOzOnBHdJdkG25ou8n7KhSpk5ssi69x07A5WJY389Z7QAJeLr15jMPP3d
H3mUcYfQRgGZPnTv0BStfeeY+JpX0JJPNNG7LDL2HeMsY4ijRJffZ4XxJxUQ6ola
Yfir4+Gp7MxvGeQ02Zz+V3PT4zj24A1zmlVNxeWG83wtZ9yOH/3sfF49zAnJ2AIQ
pAusi4nD2kLLqCgDNcidw1mOfXn+QUYtLMqLhysTpduoppfowLi8qFnpk9bcS3N+
7lON+foN8eD01Ezs7BF8ERj9a+4ssc8kRdq8tp3OIEnvtWdv4z+HG6w2God84eZc
DhFBiARLjfQkLYz1Fw9Gfzf9xP9PG3rYSALyLkeE3G82V1F4aMSWrCa1XikFVQRX
foYbKKdZMwhcSQFGgDO0hNlgg0yHcelN9r9q+dB326lqLqcB/Fw2ZdxZa7Qsa7JV
caiLV1mvv+Plz4Q7PpgRiP4FEAgAdJIgPS+g8EpMruesdk7InkaH8zQRfw8wqiVq
NzNbzEGYMw==
=fXZ1
-END PGP SIGNATURE-



pgp_E9VosA1Oi.pgp
Description: PGP signature

Re: Validating tarballs against git repositories

[Sean Whitton]

Hello,

On Sat 30 Mar 2024 at 10:56am +01, Iustin Pop wrote:

> On 2024-03-30 08:02:04, Gioele Barabucci wrote:
>> Now it is time to take a step forward:
>>
>> 1. new upstream release;
>> 2. the DD/DM merges the upstream release VCS into the Debian VCS;
>> 3. the buildd is notified of the new release;
>> 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
>> deb" and "binary deb" to unstable.
>>
>> This change would have three advantages:
>
> I think everyone fully agrees this is a good thing, no need to list the
> advantages.

It is also already fully implemented as tag2upload, and is merely as yet
undeployed, for social reasons.

-- 
Sean Whitton

Re: Validating tarballs against git repositories

[Sean Whitton]

Hello,

On Fri 29 Mar 2024 at 06:21pm -06, Antonio Russo wrote:

> 1. Move towards allowing, and then favoring, git-tags over source tarballs

Many of us already do this.  dgit maintains an official store of the tags.

-- 
Sean Whitton

Accepted r-cran-qgraph 1.9.8-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 11:07:03 +0100
Source: r-cran-qgraph
Architecture: source
Version: 1.9.8-2
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers 
Changed-By: Joost van Baal 
Changes:
 r-cran-qgraph (1.9.8-2) unstable; urgency=medium
 .
   * Remove myself from Uploaders.
Checksums-Sha1:
 5ad88620059b9743d3bfb82e9bfe18156efc4adb 2313 r-cran-qgraph_1.9.8-2.dsc
 917f0ba2d788b3a99e1885e570bdf9df21c6d32e 2744 
r-cran-qgraph_1.9.8-2.debian.tar.xz
 8d9259b4418b039fb1a4efa36f64c3fdfc79a05b 15058 
r-cran-qgraph_1.9.8-2_source.buildinfo
Checksums-Sha256:
 818c32159bef45ceb0c806ffe1eb342d24b1d76081af8923a1ad633832a208a3 2313 
r-cran-qgraph_1.9.8-2.dsc
 1f0e160e52e680d04944d8aec3eb2dcff66b6130f58bc6583f5e875328aab8ea 2744 
r-cran-qgraph_1.9.8-2.debian.tar.xz
 4dbde7c88bcbf9fc9c8f9d322f33d4b663d1acf06e2f071986391b9e8a446a01 15058 
r-cran-qgraph_1.9.8-2_source.buildinfo
Files:
 0531738aac8379fc179d2db365b0b4ef 2313 gnu-r optional r-cran-qgraph_1.9.8-2.dsc
 18f5b7f0a945c7282ac032d35e19b82e 2744 gnu-r optional 
r-cran-qgraph_1.9.8-2.debian.tar.xz
 3814cc9e79ed64d81e4672b5584ecf67 15058 gnu-r optional 
r-cran-qgraph_1.9.8-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEEkqrZAbIbS8eaR6AwVPGmYxdIZxMFAmYH5O8THGpvb3N0dmJA
ZGViaWFuLm9yZwAKCRBU8aZjF0hnE9hfD/9Sad48aSoEANqOiOwV/gfndxORs3Qb
uTlgj51CeUNpmlhtzMM+V+DE860FXl/g+4DAMQ8yIEoueqE51QmxXpXNgXCMtwim
er1/uyNR5cXoNR40ojVKOZKlLqvuJcfoftUhrUxNkbBpn08xnH4xnFwc/nsZF5e3
rCrprR7JhAJ00WgOasLA6dnAhy8h4d3qiC24Uc07vQfyOq9w5V8Fp67k+S413DCG
+cX17JaGJ1usGh3MNZzCOpoCmR6rNep47gqjhXzSXvjQ4OqOhE/cLr2CMndFmc/b
3PKei1lfldLxt7NckTRe2bO8z0YgsfN5lH8sl9ZkMHXjhdZsnhDCOM94Y+2sfPGu
SrPmbRhr4lE7aJ7CA/ftHYWU8K04qH0MpAKdji1pQ/qTIz9XGnAd7X2SEUWfXlV6
+d6sQUpBOWRssBAWCd9YnKVUOgzrOHs0NO3dZPkd1bsVqIxD7Kbw0nXs2SQYKQ92
+dAZBG+DjqwVLO5EkKxbK0KXdvLeDo3YZtyC6Y+hdgDJ0nw3Ix2ioEfjp72t5U1Q
uBFqfPLy9CpzZbG1GYEOKlEu6j18a3uHHDxmWydDCJ96xIIg5rUGHBDFst/0351C
HisgHp/E6GbMwBSrvBJbargeaXoyP/ccxCgV5rVs4fbcmi9pjQQ+rj4HpHcS/uWk
WLsdMkFGn1Cnkg==
=6eL4
-END PGP SIGNATURE-



pgpSkXLRhZsp2.pgp
Description: PGP signature

Accepted wlogout 1.2.1-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 23 Mar 2024 17:03:04 +0100
Source: wlogout
Architecture: source
Version: 1.2.1-1
Distribution: unstable
Urgency: medium
Maintainer: Birger Schacht 
Changed-By: Birger Schacht 
Changes:
 wlogout (1.2.1-1) unstable; urgency=medium
 .
   * New upstream release
   * d/control: remove swaylock suggestion, wlogout now uses loginctl by
 default
   * d/copyright: Bump copyright years
Checksums-Sha1:
 746ee0c520d59705b1f129ce48f2506f608692a8 1949 wlogout_1.2.1-1.dsc
 17a08de0d305a8648d97ee7226d322b1c7f1d73c 541761 wlogout_1.2.1.orig.tar.gz
 57d5ac378db53e2c64dfbf751c83c059c79cc05e 8732 wlogout_1.2.1-1.debian.tar.xz
 986ba44d8255a6eacc151f0bef538c91ae340760 15461 wlogout_1.2.1-1_amd64.buildinfo
Checksums-Sha256:
 5ca239e6ac795344dc5f72749d811ab1c10034bdf480cdadb99bcec09a3af2c8 1949 
wlogout_1.2.1-1.dsc
 ceb64ada0cd16d7a2603f65dd5e1c4ab15837dc84ff1541de10d3f49637be243 541761 
wlogout_1.2.1.orig.tar.gz
 93f6ecdf4609952c522db01e715abea4ddfe84e2399aeaa6f8783fe6a656c416 8732 
wlogout_1.2.1-1.debian.tar.xz
 71919ced2488c8e7b9452f78d6a0a0e06a7cc73f17bbddca54fded58dee56d75 15461 
wlogout_1.2.1-1_amd64.buildinfo
Files:
 786bf818cd840c24ab26438d816aa70d 1949 x11 optional wlogout_1.2.1-1.dsc
 491d27b5d12b4dba405d3da4f93fc5fd 541761 x11 optional wlogout_1.2.1.orig.tar.gz
 bdbae5a1a923acde944c717caf49ad17 8732 x11 optional 
wlogout_1.2.1-1.debian.tar.xz
 38c34378556d699528360cd552b0a54f 15461 x11 optional 
wlogout_1.2.1-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEOvC8tnwmrEjOtOW8KgxdYPIEvbAFAmYH5hoSHGJpcmdlckBk
ZWJpYW4ub3JnAAoJECoMXWDyBL2w4MEP/2F0jqwUKUhGOfdYl+TBOVq28zIhCFSS
jWTiQV6FS8nfWuVwhR48LGam1gnOKE1tlHNvJ329NhciFm+yK/mifaTApKjbWEDA
hktK8fDxE94zd+IMZpigtgy6rIXPYPgwkXmOOePkcXyhfun08iTswL2HHJq8YHZp
jCaJeXxjhcuLzNkEfTyEintrY3rSa7wbKnzEI4kFzZ7uaMt0RJVk3uGYH9Cts7HD
8jCy4Tr2++Er1WCxsrw3GrLDmEpUsGwY48XUB2U+e5VVetCyMGps5E05OzPujDMw
Fz9/pzbsdgHZ+8zvbZ1XVYoM+OSTC8dhfT3NqGyW7RUj/CceK5e/d0IUzka2uJbV
rVbk3jEnzG5A3NfieDX/RJU6j3LBxAQXYaxcfMNEZ+Jr/XJ7KnX3uHtVIjreXhjT
92tXI+W93fLl/xpBHUe+Gv7PiZPU0mDW4gxC5jrK+I7lh/7/b8NlrTGgEeegoJp8
CDWme+WPtygf89YeMqZglAYGizpaXeArBL2yjsCVdbJyl6hLpMxWLnK+q+xdT4Gr
osEfBF1E943zQlrOpIxjcAnb6QoeVbeioktbtlFOS5/VobHVAOAvqYDm/dFxRnHv
oql9aEM2LeqZZe0v4nEtM73onzvrhSdUOvSBxrKKz9UfRVobZLmdleK7xTXDegKQ
7ThUAmniv5Hw
=P6i8
-END PGP SIGNATURE-



pgpmoP8KFtAJr.pgp
Description: PGP signature

Accepted signify-openbsd 32-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 10:56:56 +0100
Source: signify-openbsd
Architecture: source
Version: 32-1
Distribution: unstable
Urgency: medium
Maintainer: Tomasz Buchert 
Changed-By: Tomasz Buchert 
Closes: 1022121
Changes:
 signify-openbsd (32-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Update standards version to 4.6.1, no changes needed.
 .
   [ Bastian Germann ]
   * Drop BSD advertisement clause (Closes: #1022121)
 .
   [ Tomasz Buchert ]
   * New upstream version 32
   * Update std-ver to 4.6.2
Checksums-Sha1:
 5199a3557cb4d020829c4a788c39cdfc015a980f 1945 signify-openbsd_32-1.dsc
 e19b6afd7adc005aabfb817b8ba796e81c9eae6e 107670 signify-openbsd_32.orig.tar.gz
 3e9aec659e814308f55b1ebb712b0d46f4b23f66 6640 
signify-openbsd_32-1.debian.tar.xz
 873ec318e7113251da1df0de7916a225337e803b 6702 
signify-openbsd_32-1_amd64.buildinfo
Checksums-Sha256:
 4e2556cbbc30a2459f6559cc8e1dd3d91bd418a4f2a545c7f4e8c3c4a2c62ef8 1945 
signify-openbsd_32-1.dsc
 48cfd7bfe55be01909b37e78045f240b950ea51c954bab205bcdcddc0492dca4 107670 
signify-openbsd_32.orig.tar.gz
 a3015d0cc9942daf8eb8a2bc3b5cce202aaa66f2e8afce6b349a7411e7ff70a2 6640 
signify-openbsd_32-1.debian.tar.xz
 3c68041de35eccb3e9fd945ca660817a659538f1f7525146e938f72c01427817 6702 
signify-openbsd_32-1_amd64.buildinfo
Files:
 e25bc63ab65b413bfebcc47dc3f53230 1945 utils optional signify-openbsd_32-1.dsc
 907db3c406d02dc0cdbc40e9c9c4bf7e 107670 utils optional 
signify-openbsd_32.orig.tar.gz
 01e94e3d5e9143a6630c4ca108a11eef 6640 utils optional 
signify-openbsd_32-1.debian.tar.xz
 7b6886be21a4d55ab5573ccb16f9cdee 6702 utils optional 
signify-openbsd_32-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEw4a8QcDI3JdLyqg9Y4wJ8uTJG1IFAmYH5JISHHRvbWFzekBk
ZWJpYW4ub3JnAAoJEGOMCfLkyRtSDWQQAI7Vp6dvScVaSZRzOF0iwQu3Ps5aIUMa
QRz6IXpAu7UXegujkZiBUtNRgX7t/mstoakkyLCv2rO+i9TbTxRJIsu/kTMtqz+k
0CtbYuU9dYBYxImCbBE/7uH05XX6ve8N3nIzoGAd0OJBQ39JFsiSF1PMiGokvNDv
RtjusaD35fVelfXQQeRQNkelhRynVQq2sQf6Ylb79dy/xdkbnambXluYfXcN7Ute
QfXAq27bW56Ou06ouZNcJKM/McT3Ue/ogXFMpIj4SndOgubvCb9B+walReXmPhan
/bzR4DidLKwz3DnKrclwzCNsbZKMmm1h0ntHMzI4WiaHk6hoPg2L9DASqCMbAptX
p5qEL68A8QOr9fgk5RbnWpdRf1VmX9rAeojF71hOxwuRPEzCu345HonTx6PGhIq0
Y7ekqzD8FXQhTtRDf/NIKmqEotWftfmxiGUdlkJtJKtWDInxdhgWCcPEiDAdsxNP
j7uGnj+LyJExQSmNyRnADZW1wWzys4A9g9Grqp7qE2PvOeTYBV+9PsG0zDwUeMN9
ccR1YRpU5Aq/oW8vTyi0HoIwpsDHwMlJOIpYVtS6yW2zagLhQ/5SwifnFnGjlOsR
XFYcPRhAxbgRCfMG4QIM02YXtsmRhZMjlBqX0UJB8Oc3gpYXw9ZRBe7nX0eZoXOh
znfj4upis1kj
=5/js
-END PGP SIGNATURE-



pgpOA0AWSWvui.pgp
Description: PGP signature

Re: Validating tarballs against git repositories

[Gioele Barabucci]

On 30/03/24 10:05, Simon Josefsson wrote:

Antonio Russo  writes:


1. Move towards allowing, and then favoring, git-tags over source tarballs


Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends quite a lot
compared to building from tarball, and that will more likely trigger
cyclic dependencies.  People that do bootstrapping for new platforms or
cross-platform dislike such added dependency.


Most of the time such added dependencies could be worked around with 
build profiles and cross building. More widespread support for , 
 and Multi-Arch annotations can greatly reduce the number of 
deps needed to bootstrap an architecture.


Just as an example, bootstrapping coreutils currently requires 
bootstrapping at least 68 other packages, including libx11-6 [1]. If 
coreutils supported  [2], the transitive closure of its 
Build-Depends would be reduced to 20 packages, most of which in 
build-essential.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=coreutils=amd64=9.4-3.1=1710441056=1

[2] https://bugs.debian.org/1057136

Regards,

--
Gioele Barabucci

Re: Validating tarballs against git repositories

[Iustin Pop]

On 2024-03-30 08:02:04, Gioele Barabucci wrote:
> Now it is time to take a step forward:
> 
> 1. new upstream release;
> 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> 3. the buildd is notified of the new release;
> 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
> deb" and "binary deb" to unstable.
> 
> This change would have three advantages:

I think everyone fully agrees this is a good thing, no need to list the
advantages.

The problem is that this requies functionality testing to be fully
automated via autopkgtest, and moved off the "update changelog, build
package, test locally, test some more, upload".

Give me good Salsa support for autopkgtest + lintian + piuparts, and
easy support (so that I just have to toggle one checkbox), and I'm
happy. Or even better, integrate all that testing with Salsa (I don't
know if it has "CI tests must pass before merging"), and block tagging
on the tagged version having been successfully tested.

And yes, this should be uniform across all packages stored on Salsa, so
as to not diverge how the testing is done.

iustin

Accepted node-node-sass 7.0.3+git20221109.ee13eb9+dfsg-4 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 13:35:38 +0400
Source: node-node-sass
Built-For-Profiles: nocheck
Architecture: source
Version: 7.0.3+git20221109.ee13eb9+dfsg-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Yadd 
Closes: 1068064
Changes:
 node-node-sass (7.0.3+git20221109.ee13eb9+dfsg-4) unstable; urgency=medium
 .
   * Team upload
   * Declare compliance with policy 4.6.2
   * Drop build dependency to libuv1-dev (Closes: #1068064)
Checksums-Sha1: 
 934b5e2ab6d0ec8c4a28d0ee464d7ebb9bdef651 5896 
node-node-sass_7.0.3+git20221109.ee13eb9+dfsg-4.dsc
 f6616e956a717950c258c86f034a4aa7783172c5 18456 
node-node-sass_7.0.3+git20221109.ee13eb9+dfsg-4.debian.tar.xz
Checksums-Sha256: 
 af2dd6ca8a68cb1f12466287cbb846587ad176b94ba54d15c38865fe0727b2f7 5896 
node-node-sass_7.0.3+git20221109.ee13eb9+dfsg-4.dsc
 a4925d8bed7998764ee0c2af1e5a9bf367c29015fe81b631e8267f41d55496e5 18456 
node-node-sass_7.0.3+git20221109.ee13eb9+dfsg-4.debian.tar.xz
Files: 
 e6c7dacbefbabc96a2dc78f482cbcf8a 5896 javascript optional 
node-node-sass_7.0.3+git20221109.ee13eb9+dfsg-4.dsc
 27665475436854a588ee1e6ba27110e7 18456 javascript optional 
node-node-sass_7.0.3+git20221109.ee13eb9+dfsg-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYH3S8ACgkQ9tdMp8mZ
7ulQWQ/+L+SLCZ9jtXBQ5obNKt/zxJ4q+zZFElhiycyQ757TugbLGMiqfTJvGmUM
l9/a5hrK3R2tq5WMw8E6bX9+Xus9P/gdVXLy1Epjwdhidc6o/Zl3cAaLGZqZ6JZT
4EzW11n4riHK90LG86slaD15HniiyEmirfUG+Eppl4u/exfzenaKtMGMxktTRxaX
bbF6EqeUjmacSLuOUBL1BnvW0voX6PG4oon9Y63qh6Y8OPDYPek6yqrD129pn8RF
AT2GH5TKEQv8k7DxACbLeYulS5CmUY608D1j1M5RLDEyJfE6YYh+pGdRXfnUMwXc
F5oxeRIre+gdWgsXQFwQkL3C/VXAr7/nJ+9Zq7cEpNkKlIzb/uRDT65CzEq8GllK
VnbrR6HRHfQkBudGKYLiksO5BNDotMWEt17ezusPoOR+d9s+u2LgPRn+G0af9eos
78SXwNrQN60bzrUTpo9qqboUgqtqj9lHTiNjj36UuZO4RoyYSuu1AZT78nfSylA+
fSb1wv3dtzzVbKkfoZkPug+GTZSkUcrfFnyVXVX9d5WiuqQLp+y3RXHlvrRnh4As
Z1BHUnPPFGutmMppol+U4Pr5eBkMvJuY8OqDTTXRhu2WVQklXx6cl3B1MNtcRo6b
nSERlDI7BJRIm3nmX87VNTMxZOSBWT5DhBKhmA1+mYAqdGq+s90=
=PkEb
-END PGP SIGNATURE-



pgp8G60eb6Eyx.pgp
Description: PGP signature

Re: Validating tarballs against git repositories

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 09:58:22AM +0100, Ingo Jürgensmann wrote:
> > Yes. In that specific case, the original xz maintainer (Lasse Collin)
> > was socially-pressed by a likely fake person (Jigar Kumar) to do the
> > "right thing" and hand over maintenance.
> > https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html
> 
> In his reply to that mail Lasse writes in 
> https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html:
> 
> > It's also good to keep in mind that this is an unpaid hobby project.
> 
> 
> This reminds me of https://xkcd.com/2347/ - and I think that’s getting a more 
> common threat vector for FLOSS: pick up some random lib that is widely used, 
> insert some malicious code and have fun. Then also imagine stuff that 
> automates builds in other ways like docker containers, Ruby, Rust, pip that 
> pull stuff from the network and installs it without further checks. 
> 
> I hope (and am confident) that Debian as a project will react accordingly to 
> prevent this happening again. 
How?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Antonio Russo  writes:

> 1. Move towards allowing, and then favoring, git-tags over source tarballs

Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends quite a lot
compared to building from tarball, and that will more likely trigger
cyclic dependencies.  People that do bootstrapping for new platforms or
cross-platform dislike such added dependency.

One response to that may be "sorry, our concerns for supply chain
security trumps your desire for easier building" but so far I believe
the approach has been to compromise a little on supply chain side (i.e.,
building from tarballs) and compromise a little on the
bootstrap/crossbuild smoothness (e.g., adding nodoc or nocheck targets).

Moving that needle isn't all that trivial, although I think I'm moving
myself to a preference that we really need to build everything from
source code and preferrably not even including non-source code files
because they may dormant and activated later on a'la the xz attack.

An old irk of mine is that people seems to believe that running
'autoreconf -fi' is intended or supposed to combat problems related to
this: autoreconf was never designed for that purpose, nor does it
achieve it realiably.  Many distributions have adopted a preference to
do run 'autoreconf' to "re-bootstrap" a project from source code.  This
misses a lot of generated files, and sometimes generate incorrect (and
possibly harmful) newly generated files.  For example:
https://gitlab.com/libidn/libidn2/-/issues/108

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Ingo Jürgensmann]

Am 30.03.2024 um 08:56 schrieb Lucas Nussbaum :

> Yes. In that specific case, the original xz maintainer (Lasse Collin)
> was socially-pressed by a likely fake person (Jigar Kumar) to do the
> "right thing" and hand over maintenance.
> https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html

In his reply to that mail Lasse writes in 
https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html:

> It's also good to keep in mind that this is an unpaid hobby project.


This reminds me of https://xkcd.com/2347/ - and I think that’s getting a more 
common threat vector for FLOSS: pick up some random lib that is widely used, 
insert some malicious code and have fun. Then also imagine stuff that automates 
builds in other ways like docker containers, Ruby, Rust, pip that pull stuff 
from the network and installs it without further checks. 

I hope (and am confident) that Debian as a project will react accordingly to 
prevent this happening again. 

But as a society (that is widely using FLOSS) I would also hope that our 
developers will get proper funding instead of requiring them to maintain such 
software in their spare time. 

-- 
Ciao...  //Web: http://blog.windfluechter.net
  Ingo \X/ XMPP/Jabber:   i...@jhookipa.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Accepted satpy 0.47.0-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 07:48:15 +
Source: satpy
Architecture: source
Version: 0.47.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project 
Changed-By: Antonio Valentino 
Closes: 1068007
Changes:
 satpy (0.47.0-2) unstable; urgency=medium
 .
   * debian/control:
 - Drop dependency on pythom3-pytest-lazy-fixture.
   * debian/patches:
 - New 0008-Switch-from-appdirs-to-platformdirs.patch (Closes: #1068007).
 - New 0009-No-lazy-fixture.patch, workaround for #1063957,
   * debina/rules:
 - Skip broken test (test_correct_area_clearsky_different_resolutions).
Checksums-Sha1:
 b790c92684669654ec4ebd5bb53a9c70842a9c02 3258 satpy_0.47.0-2.dsc
 be3ddd7a467a8d897417320a3178ed40515beff2 965760 satpy_0.47.0-2.debian.tar.xz
 631771c847235f1811c814c0acf476be9026941b 22393 satpy_0.47.0-2_amd64.buildinfo
Checksums-Sha256:
 c0873e4291160188210606cf13dc0ca94d5ad7ac9e3bc29a4541cf41780ceef7 3258 
satpy_0.47.0-2.dsc
 2677c3901cee4710102dc60b47dd30fd5c50bd0a24ea89cfd26999a931072f71 965760 
satpy_0.47.0-2.debian.tar.xz
 ed0c6d0bec8ecf4c1fc435861505126e40761917a72a45a16145ef08b8386349 22393 
satpy_0.47.0-2_amd64.buildinfo
Files:
 a39a9180fb30fdb87a0d882024ceb1c0 3258 python optional satpy_0.47.0-2.dsc
 bd3d8b139074496b3bfe5b67f405229d 965760 python optional 
satpy_0.47.0-2.debian.tar.xz
 b34396fda67f1991f6e765bdf0f0eb9a 22393 python optional 
satpy_0.47.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEEO3DyCaX/1okDxHLF6/SKslePmBIFAmYHyvwdHGFudG9uaW8u
dmFsZW50aW5vQHRpc2NhbGkuaXQACgkQ6/SKslePmBLrlQ/+LX6nGFQ4K63Lao/t
qFEJBUPVE/cYe7JrvYijrtYadg2nieHGlTjZo0RXf0sSP1iihqMQqv2UcjubBVI4
2fjNTr3pzmZ4G0a7Fn94sRYPn8IyUby3+aNwdoXwhLTBWr5im/WuBlL0SNkhNJYS
egKTF+3UrbbkgI0zR0Bc4EulQKMd4NVugeX7l/AWIdELfmEfq2fZ00vqOkEvgUby
+e0KljPgmoApwLZhIG99qFmjuIL6Yf/KFf4wyRjiQvqMBpSOJqTdvZ1lCHhU0JqZ
9ThsDBxoeYJBCE7V9RTspsfHsfbrnlNR4wteBd0lk6ljD4cUIf7ujt9NAcr2aEQM
SujIv4gSsXyCSChx6hLjUPgccG3lnA3fotcHZw5lVtwv5uIHpGntUS0lGf53EKny
PLCYLD4RssQEfJLW1pYiw8h/46AtdNdoS7H1GXAmALAv/buOOZXMmpbWct33/u+n
IJ5J58FxfoBnZTM0rmILWW8P38eZ381GCKVyJoKOIqrDv5dnaH6Ufho8jFY+2JUW
dQaR28g2ULrijrE+TIF1vR5qJBjrNmc4jQzdkWt3kouY6t3mbMiF6ny+EPwV7Ngz
HP4XBFEZnZYwD0yNPqImV0padp6+y5Xv4ImSnKZ+BkMv15aLgwuFhAR6Wx6e5Vls
0iF4ceBY84uLfOQeYUXehYRj2uc=
=Ozhv
-END PGP SIGNATURE-



pgpXbMYQxgCEb.pgp
Description: PGP signature

Accepted memcached 1.6.26-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 30 Mar 2024 09:10:43 +
Source: memcached
Built-For-Profiles: nocheck
Architecture: source
Version: 1.6.26-1
Distribution: unstable
Urgency: medium
Maintainer: Chris Lamb 
Changed-By: Chris Lamb 
Changes:
 memcached (1.6.26-1) unstable; urgency=medium
 .
   * New upstream release.
Checksums-Sha1:
 e6579478626b24ef930a0bbc7bca796107be 1999 memcached_1.6.26-1.dsc
 9ea8c083611def09872fbb8f045cad5d592b61ae 855732 memcached_1.6.26.orig.tar.xz
 777ef1626c41ac703899b72fdc72eee24a78dd65 16728 memcached_1.6.26-1.debian.tar.xz
 ae60140941c5d44f4a4c98ffd9a6eec0fe83680d 6806 
memcached_1.6.26-1_amd64.buildinfo
Checksums-Sha256:
 d999ca84f71be8bbf1de7c6bf83cc83a04acf77d948e45fd549e8736f8ee6415 1999 
memcached_1.6.26-1.dsc
 c2f9e26ee6952dc2f302682f462116a133e337bd0c137bf82d90ddbd98330dde 855732 
memcached_1.6.26.orig.tar.xz
 6c5a0ca558a35c1b65523dd410961970e14a84c676ca1f786bf9947443c14726 16728 
memcached_1.6.26-1.debian.tar.xz
 96d908314ead0b5eae932bef1ab100b35108a57e63d684c0d71824199fa69031 6806 
memcached_1.6.26-1_amd64.buildinfo
Files:
 8a8886091b2e363ee162ff0a95cc2b7e 1999 web optional memcached_1.6.26-1.dsc
 bff5659d99a498dc59d454a6483e13df 855732 web optional 
memcached_1.6.26.orig.tar.xz
 033ecf1e3315a817731a7307848e05b0 16728 web optional 
memcached_1.6.26-1.debian.tar.xz
 4f2e870a126317bf041bfc93e156181d 6806 web optional 
memcached_1.6.26-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmYH2AAACgkQHpU+J9Qx
Hlio5g/+Kp4SwhLuGPWbreaRZsul5x8SleaLwb92KSaTBAPyaDgHNuHNtXXpHVG3
ytHdcOiBOnsDJ0LrplA4M5m5FdA8/UT6C5Ft47/d7Cw/XV8Lc1i7JQG2cFtbpQyj
b2Q9Se4zRtmvwlau1/V+il5P/sB9Csmt3OhbGa17H+kbwJx1RaKGKzdRzYrcqrQi
L7Cx7Sn18OJgMZV3ktb3V0OhwyvT7solkbm2zaYolJHCmrQgBF4IGtBHQlrEATrw
qdBBlCeJ2BU7k3MlK1U3nM0GixcyOL6NAED19CZ2t6Yp3alB/GxaXvKan8zpaSD0
BlW2cXIUdZRGEkrSfBAKhNpJh35m4FSVkZ/7jdKlMmFv2uCdJulVLWrRJ1oYm3J0
CSASsGv533ZqxLcBu7gP0XjWn7+dHv+UvCHHY/vMSeB3yeDlX6mx6CDes+bnks1P
UbJf+VYdKwpa48dC0SFATm9q+g4VsupoVT/ortcqxuhDuNCr9woeLrBRJbMCvTuU
dXtjHQbnNXZewb8xdCYKWuNLCmFBSuWuTRrVCAcjnpXBM+lQW7zTOhBv7kcp5Pbj
aVvNnVRujbOZx2QBtOWSk95riuEd7Tbid9GALSvo4zeqxxtDzVuw7yRghcGxHlWh
cgAybkXlTbF1lR5d31jutdS6qsI+CrAu48TotH5RFcXy9K6LAwc=
=1G3y
-END PGP SIGNATURE-



pgpQ8iCNqIs5O.pgp
Description: PGP signature

Accepted firehol 3.1.7+ds-4 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 08:51:21 +
Source: firehol
Architecture: source
Version: 3.1.7+ds-4
Distribution: unstable
Urgency: medium
Maintainer: Jerome Benoit 
Changed-By: Jerome Benoit 
Closes: 1068046
Changes:
 firehol (3.1.7+ds-4) unstable; urgency=medium
 .
   * Debianization:
 - d/ifupdown/*:
   - d/i/ifupdown-firehol.sh, move to bash shebang (Closes: #1068046).
Checksums-Sha1:
 dc0f6f6812c28a31dc1d814aba891c87224eccb4 3185 firehol_3.1.7+ds-4.dsc
 dde24d95f4b2dc3586cc942ab44c194f00e7240b 26944 firehol_3.1.7+ds-4.debian.tar.xz
 10a3ab882a85e3f84fba1a6d05154ec2d601fd87 6713 
firehol_3.1.7+ds-4_source.buildinfo
Checksums-Sha256:
 877280ebc6cfe7f82e827d2460d444b43eceb8e6e43fce44546883e6f4c6b171 3185 
firehol_3.1.7+ds-4.dsc
 e58a05d3cc80bc7d87d6f3eea06093cc1b85f23bc5bcea0952812cf2f1cedda2 26944 
firehol_3.1.7+ds-4.debian.tar.xz
 a89ddc2c8d5d16c5e9c2bf547cd68383a3ffe7360cfed66e9fe1d28c366b3dd4 6713 
firehol_3.1.7+ds-4_source.buildinfo
Files:
 052bf15d8bbee33801b50cf223a380ea 3185 net optional firehol_3.1.7+ds-4.dsc
 d14b03a98fdb78a756169be8b5e837f0 26944 net optional 
firehol_3.1.7+ds-4.debian.tar.xz
 04aae94022c67ef73946c72100d70bc7 6713 net optional 
firehol_3.1.7+ds-4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQRJBAEBCgAzFiEEriiuFXEN/x2H5adiP5IZpn82xosFAmYH1KkVHGNhbGN1bHVz
QHJlem96ZXIubmV0AAoJED+SGaZ/NsaLfWwgAKPVSzJGLiFwiL2By3U1PCczuExW
rlgCHfYkTEkwK1p/SAPKKNKjBat+kQFyC0Br62NnTwozr4ELgjtiJpIQ/S3XDxId
jQzu5cobcpxMSCN4hkfmqHlPIo8RLdKFO230Cjc/mp5RoWy8LCqtUZJI/Twm+Erp
w2Ea6eu6pPn1z4oy1DxPDLO3gz0zxc34AsKOn9IgAn/17vnBw4hqvBhc72yQTF2K
G152cOQOX7PP8Bjru8UBhZgUpfWEc76g58yWuWdojaga8jhvM0v0YWE6DCHlaTKJ
RUNbMWxQ+eBi+ZrraBRkuiR4PWaHK6fibOkQxx1QwGBgNoWJv6gnk8ZUx3M/nduY
XnfvJnf7n1RXTvU77ftkGjv6fwNqbeamyUli4/+Ytn6PhwDNNpChTYQp9PTj9bSX
SacTDKq7HQfjqfXHVwqC8BLvBXhDyYPIfwlAi4gW5BoaC7n6ht5mmSSuNeb4K61W
BbaH7db9ug8wR5hcqPMspMA+wGU/gmgo7+bg2/ImgcX3j1PYfU/mklE6V/8PNw0S
qWbHLKEZ9f/lgaf9QO2jNX2r1BGBQYGMcab4Azlzvy4LXfS+nEVkmyBZsdz6rtVC
JUIikNY5ULMkrrluvmNKa7nAsE2Ccfp5qCUQif8F47MOPOLwdiBsHpj1IgIUSocT
tHkmFyQnnKGCPsXzbGv2CinNfxfX6drMSVW3rOK9HztyNMOFldFB9L97wR3qDJj4
d42jwGjaDNwXtPmWsNv8wogvxCRVyrXb7FEcY/9H9gNPCaiBNgRB9mIfXRJuxo4P
vC0OCRQdHtvbqb2p6rEyktrY/iwsOGcn3KMHU+HtfeUrNkjD9ZMAtd8Mr5mX7CuT
Y7yNUnXNclxV+0pq7I5kAJd462fQHDMcHsUEj8++iQk+oF1jxw5ylOKYxxILNwmC
XB9puED7ScqCZmKWUVEwF+totinqwYoRQlx01kVDeU6RV82Hks/MJekrGc7WbVol
gUVHqyQ/w+Sqp2JebdDZslp9mBe9OXXQ+SG+vZAbdiQU5sjrPuMTf59C2pK1nc/Y
bAvdfDZF229VuZ6hsYDigkCGhHZtAPcEnBhXXlY5P5Wrr0+QgSwGe6+ueMZ7fzBS
cSGU2D8/8suPQnPLrcshgS78rxUb+BceBNqsj0MLEk39dwTC9jKTCBMiit62GvBh
5Do/l1Sh+bY+fKnQSH9BrP5E3ErQzFWxffN13xh/XOVc3RPvkl6EIL6RWobjqboK
4OX7Bx9SdjUnUfQxMYz8m6MHV04MflwpazFx9EO5Mq5t08tD370epnnNb8fdD0Y8
tJgCWX/Tf3Y7BU3lbnRTuzU0q/dXZSpKgoHBvBzLoGsWIjq582LwUhidNTM=
=6ZnD
-END PGP SIGNATURE-



pgpT2QZ0pOWXr.pgp
Description: PGP signature

Accepted nacl 20110221-14 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 09:17:37 +0100
Source: nacl
Architecture: source
Version: 20110221-14
Distribution: unstable
Urgency: medium
Maintainer: Jan Mojžíš 
Changed-By: Jan Mojžíš 
Closes: 1066444
Changes:
 nacl (20110221-14) unstable; urgency=medium
 .
   * d/p/0002-fix-ftbfs.patch add, fix FTBFS due to
 -Werror=implicit-function-declaration (Closes: 1066444)
   * d/gbp.conf: add [pull] track-missing = True
   * d/copyright: bump my copyright years
Checksums-Sha1:
 33ac799b625fe304000192613646528d2720511d 2013 nacl_20110221-14.dsc
 1eeb130b36ccb1361a8269497fe1feabe1aa5aa7 14124 nacl_20110221-14.debian.tar.xz
 44e614f0524260b34c56e412a8624764ad4d97e6 6464 nacl_20110221-14_source.buildinfo
Checksums-Sha256:
 e3d4ef3513dbc7cef7473e7a7e4222e292c6e8694c0fed35104cbe841eb64b89 2013 
nacl_20110221-14.dsc
 edb70172c7dd7164d88aab96ebce0954dfff4f75d90b03fbeed64985fd323b18 14124 
nacl_20110221-14.debian.tar.xz
 6bd3ceffd4fbd9cf1441859775803b54e8c197e63e19ce328600e9c0de3575c6 6464 
nacl_20110221-14_source.buildinfo
Files:
 00e6a74a53f747e2fffe535206893c9a 2013 libs optional nacl_20110221-14.dsc
 9a87dc3cde3349ea956e2a177767f1b5 14124 libs optional 
nacl_20110221-14.debian.tar.xz
 e9f053c24748b9c0369e975da8b7e54b 6464 libs optional 
nacl_20110221-14_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEE0Aiwwj2EeeRrn8uQRdpRdJaTn/kFAmYHy5IVHGphbi5tb2p6
aXNAZ21haWwuY29tAAoJEEXaUXSWk5/5w/wP/iNuU2o0mPZlf5UIWHfLSJBP5YOV
mxPQSmjgNktJKs6JbkXUllp8O5pTuUiuJDYHvEonUokxGiEYBScAJ54mYKRE/jbt
ZdaRhcYe2Hwajz2gso2uAm3HLm3E6erXDY3WOcL2GElIzAscGMXZPafVUvJpV5EF
UN3H4GZxHeDjRfhGO43d5OAPNaVGCMTnnI8wZPBVMULBerK2+/Y80y67bKNL/bJS
cZhDb+sgCa5UI0omKyMP7rk30zs5+OFZbtZXBFtLWQ2TfrYGNg2yz3zPDOXWPjRv
uNkNUcdPmL+lyzpln8yCNQUq5XCVoJgfa2U7YATCHV+h4nEucd27rC47GV1SLjNO
jGM4WbEA/NzsNi7S+JgHXwsPBdf5dBeJi7NRsEqTTurD+oXkbf4pK+IpHZE9LQ6y
w5WjwBb8tb3jiorYlY8+39RMTs8KT+DscfLVOtJOajSTWzDSWSdEowaCRnERMx4E
YXnPs8mVeOlXhEjLtFV/Da+EcH/9+BrY4Rk6aJpuLQjk+Tp7+S2jAkMLN4451WWE
hne9afLW1tXEdM2PdN+U186N8uc1J5PKFnieffzlcqZKmM2kOcF9BdzvCejxMFeL
JjvU0OqPVqWYWeBTyBRBwW21ON2zFVFkrMcFQTtVwxt3JjLn/PWU8W5tICaKPHvt
G2LGzPT4FyhmLlXZ
=M3Iq
-END PGP SIGNATURE-



pgpsSa0a3FcYq.pgp
Description: PGP signature

Accepted qtdeclarative-opensource-src-gles 5.15.10+dfsg-3 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 11:21:30 +0300
Source: qtdeclarative-opensource-src-gles
Architecture: source
Version: 5.15.10+dfsg-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers 
Changed-By: Dmitry Shachnev 
Changes:
 qtdeclarative-opensource-src-gles (5.15.10+dfsg-3) unstable; urgency=medium
 .
   * Add explicit dependencies to disallow mixing gles and non-gles libraries.
Checksums-Sha1:
 893966cb346b9273958bfd450e26a701af758b27 2716 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3.dsc
 3b1c97fdb1771a06ed3aeb5f5924bd5115e6810e 39124 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3.debian.tar.xz
 a1db92b7fad12002566714235b0d8b8bc168b090 9182 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3_source.buildinfo
Checksums-Sha256:
 996ce293ea41a18f71e46a4cfa8a7b4f3357950f4509a6ca12586fdca81fc2c7 2716 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3.dsc
 1c92ff0c772cd79330c28656672ef744b873507f2352b131dbfac74fd9ee3bd5 39124 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3.debian.tar.xz
 129ac7a5a51dc244db2b3fc57259a28dd21c6df940105c90587462f789bbd511 9182 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3_source.buildinfo
Files:
 b5587822d79116ec447437166e8f8464 2716 libs optional 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3.dsc
 93b474c92156c3e5a634ffec81a44eff 39124 libs optional 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3.debian.tar.xz
 4731de3bf6f7d4f4741665c676c3d721 9182 libs optional 
qtdeclarative-opensource-src-gles_5.15.10+dfsg-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEEq2sdvrA0LydXHe1qsmYUtFL0RrYFAmYHzHETHG1pdHlhNTdA
ZGViaWFuLm9yZwAKCRCyZhS0UvRGthxhD/9ymaNL/cXHmDhyQ3FRNNmuXS1rPIAq
ePrszrNtf2W/T/CniHivqOjRNhMvjNmZTA6ygYi5hkHTBeox15WeAOcXiriQX14+
bTt1HgHibGt5+aisDy/25SShw4elvCEi+3KHLYQe5tWbt3ZX+UwbqNv8WI14jC5m
FjfNaMvwlO7Wp/6Uif1o2oFHZSebEpQpyIgNJ4/F/jnsRJMlZu6z/ocEgBVp1EJf
zC5WG38n2+g0wqSGGULObNUf+8D4R24wGR9le01zJdYDCmipCZFB4eNQ1+JnW0U6
PuPfCJO/7lRJTqWNLvryEPztS3HSizsy0vTXUpZfl+EzIuwFV+aFKQ/Ou7widaSF
rTWmP4nsw1vYqX+WjxMvJ+zbU7WVDSAmnq5STwjXSKOD++RploFndlC9wJWGy8iB
EAN+NTACnq/enCwdoiZsfD6i5+PJEndpKYgkySvwCQSHXF5bsnWQSuO3ihWD1rTc
VMDYsRxoPhQre3VWjiTp7haJJLW8aBt9XikcWbKkPeCyBXMXBJj9YSOUH7WfDwOM
bERrODGdT+24Qc+Bz8jLf6A3uNDZBMnCI0kEXvngsSpWcbC1vm1tSGKFmQEnmz/q
PK2RR18Xk4yWYiUBCt7NB3ql21h/2akFgyxaBKqxhco1iZBTWn2fGp3U2UQPl5j8
quPd6PWCopQNew==
=Xatj
-END PGP SIGNATURE-



pgp59Kn_NFFu8.pgp
Description: PGP signature

Accepted golang-github-go-git-go-billy 5.5.0-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 29 Mar 2024 20:16:20 +0100
Source: golang-github-go-git-go-billy
Architecture: source
Version: 5.5.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 
Changed-By: Simon Josefsson 
Changes:
 golang-github-go-git-go-billy (5.5.0-1) unstable; urgency=medium
 .
   [ Maytham Alsudany ]
   * Team upload
   * New upstream version 5.5.0
 * Update (B-)Deps
   * Add  to golang-gopkg-check.v1-dev B-Dep, remove from Deps
   * Bump Standards-Version to 4.6.2 (no changes)
Checksums-Sha1:
 f93f70158936b4f41756da15e2c97d2f9d423322 1811 
golang-github-go-git-go-billy_5.5.0-1.dsc
 9e64e3ac84570646397edec5a651f46167a670df 40048 
golang-github-go-git-go-billy_5.5.0.orig.tar.gz
 ac76840d30485aa095d10e74f1fdfb807b8a3753 2384 
golang-github-go-git-go-billy_5.5.0-1.debian.tar.xz
 70c93b9cbcd1730a20e3e1337766376160d2fdad 6511 
golang-github-go-git-go-billy_5.5.0-1_amd64.buildinfo
Checksums-Sha256:
 8f6898916c53b067c1bc1c1f02afbed32655924c27745346603bf61ed75aa05a 1811 
golang-github-go-git-go-billy_5.5.0-1.dsc
 1c0ae06207d8fa1210bb6233fc1a50f9a4bbc2defa8aa5f8f221ddcb595d34f4 40048 
golang-github-go-git-go-billy_5.5.0.orig.tar.gz
 0f3ecb972a1095c8b43d3a103954902e7e402fc7160520fd43c0dc3606f5cfce 2384 
golang-github-go-git-go-billy_5.5.0-1.debian.tar.xz
 778a66ee1914c545706f271004e409337145cf9f83e445eed4991d34e2b80f7c 6511 
golang-github-go-git-go-billy_5.5.0-1_amd64.buildinfo
Files:
 ec1053ae7a9fd6642dda2de0abf89fba 1811 golang optional 
golang-github-go-git-go-billy_5.5.0-1.dsc
 73400bd4e4a50df2175b004cb5656d79 40048 golang optional 
golang-github-go-git-go-billy_5.5.0.orig.tar.gz
 13cee55354fbc92cabc15f0ff9a19ec8 2384 golang optional 
golang-github-go-git-go-billy_5.5.0-1.debian.tar.xz
 02024935c1f9b3bbbd556266f96f2e5b 6511 golang optional 
golang-github-go-git-go-billy_5.5.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZgfOHBQcc2ltb25Aam9z
ZWZzc29uLm9yZwAKCRBRcisI/kdFot3OAQDpSEXJHx3KzJSdx0eWOSvy0k72VXgz
nB3wTFNug1gpvQEArfDC11LWUZKHE4KgANuqYmKQ4BjZIPdiBcARrk7boQs=
=Y4cX
-END PGP SIGNATURE-



pgppPr50QEhD0.pgp
Description: PGP signature

Accepted gnome-shell-extension-dash-to-panel 60-1~exp2 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 10:24:01 +0200
Source: gnome-shell-extension-dash-to-panel
Architecture: source
Version: 60-1~exp2
Distribution: experimental
Urgency: medium
Maintainer: Jonathan Carter 
Changed-By: Jonathan Carter 
Changes:
 gnome-shell-extension-dash-to-panel (60-1~exp2) experimental; urgency=medium
 .
   * Upload to experimental
Checksums-Sha1:
 eb7ff2838d0ae03af5bfaf506586af1148c95995 2209 
gnome-shell-extension-dash-to-panel_60-1~exp2.dsc
 90412658ae4f9cc2e1b147b97033aa714d9fa505 21206762 
gnome-shell-extension-dash-to-panel_60.orig.tar.gz
 dc1d72080f4f62ef38fb0b905e248341eee6d6ee 3824 
gnome-shell-extension-dash-to-panel_60-1~exp2.debian.tar.xz
 460af7d169303278746d2f327453c61899a1d790 6424 
gnome-shell-extension-dash-to-panel_60-1~exp2_source.buildinfo
Checksums-Sha256:
 bfa66b7708e08fe13653e05cb123e375a6b9f2ad81178a6ac43344a750505290 2209 
gnome-shell-extension-dash-to-panel_60-1~exp2.dsc
 e58178fa2088d633818f6089a5a2135494869bddcf95cd70ca7efb6a201e 21206762 
gnome-shell-extension-dash-to-panel_60.orig.tar.gz
 9b8cb77a973b2752c6d25634bffc0afe2c389ca1ee1b1b54602346e935061c23 3824 
gnome-shell-extension-dash-to-panel_60-1~exp2.debian.tar.xz
 abaa78528e648d4d129d8493e2bb5f77982a9ce974bb8a3d8b83a65557c58aa3 6424 
gnome-shell-extension-dash-to-panel_60-1~exp2_source.buildinfo
Files:
 e761bc4ed18f3131405ae5480d833278 2209 gnome optional 
gnome-shell-extension-dash-to-panel_60-1~exp2.dsc
 3feaa7092fbf93892b3bc3468f6d7106 21206762 gnome optional 
gnome-shell-extension-dash-to-panel_60.orig.tar.gz
 08894ffc628a87af480f0abc1494a36e 3824 gnome optional 
gnome-shell-extension-dash-to-panel_60-1~exp2.debian.tar.xz
 ec41b483084651eec59e8b5b39d20977 6424 gnome optional 
gnome-shell-extension-dash-to-panel_60-1~exp2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAmYHzFIPHGpjY0BkZWJp
YW4ub3JnAAoJELAdGnKsjcmhppYP/0jyUiBr9b8vYdcXeDE3V4/uDwJ1cq5YQwSX
HlJmM1secEx2EuMhICiIQu51ymeZ2SMRoiW2K5i0xKGz3XooQ9myvuQWm6RocSf3
jMBSFA997j5V+BjiyJpuffM4HXfWh2FL8xdea/dcEo6vYOc1+5QvYWozWyhaGQbc
p3qVkz8O7vimLQDo1shd+Or52d9+T9UmupPmGElme9WkqFV+2LhRVIV2ZNtud8cI
LKZZTt6O5FJCNS8DyqmGKixAejjGBpoS5QhrPwEMApHz6fJ5JsViMOcHDu2a7IZF
T46zycHrqGr3vUm8IckWO9UU98e+blRKavRgP6okI2D7YxrEkPIGuvChiK8vR+zA
53wtXMK9pUhOMBfxvbK/6rPQZs1xWZFxhhaw9SvN267J53KrsVBCExUrZ9DNyD/f
9Mah1RAC13otcNvMgJ6ms8CbXZiCBzSsDqgseFAS4fQQHDCnVmDs56RwJdGP2anY
Q00FYwLldfDG6nGhIEdYmR5teZyaZJBIMek4e7DR1OI5f2h6NArrHS0CQZaLm8bZ
EG++urXgrsoGN4WxOxpu06Gh+UkLgbSJ6mVUB2rfedcW569Hol5R8KKHa8SXJuif
7zfKldG8C5nAIsyX47FIsBRJv4F4LmeTabZH69yNDpgSt7BY0kumYWZS/6DCJwSE
J4zdz1bH
=gcJs
-END PGP SIGNATURE-



pgpMYYDHLOqSK.pgp
Description: PGP signature

Re: xz backdoor

[Jonathan Carter]

Hi Russ

On 2024/03/29 23:38, Russ Allbery wrote:

I think the big open question we need to ask now is what exactly the
backdoor (or, rather, backdoors; we know there were at least two versions
over time) did.


Another big question for me is whether I should really still 
package/upload/etc from an unstable machine. It seems that it may be 
prudent to consider it best practice to work from stable machines where 
any private keys are involved. For me it's just been so convenient to 
use unstable because it helps track changes that affect my users by the 
time it hits stable and also find bugs early that I care about, but 
perhaps I just need to make that adjustment and find more efficient ways 
to track unstable (perhaps on additional machines / VMs / etc). Not sure 
how other DDs think about this, but I'm also curious how they will deal 
with this, because there's near to no filter between unstable and the 
outside world, and this is probably not the last time someone will try 
something like this.


-Jonathan

Accepted scalapack 2.2.1-3.1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 11:47:52 +0500
Source: scalapack
Built-For-Profiles: nocheck
Architecture: source
Version: 2.2.1-3.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Andrey Rakhmatullin 
Closes: 1066328
Changes:
 scalapack (2.2.1-3.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Disable -Werror=implicit-function-declaration as that's the only viable
 way to make this build (Closes: #1066328).
Checksums-Sha1:
 fdefdc13fb04e84c63576ec4649242cc6c32b7a7 2677 scalapack_2.2.1-3.1.dsc
 b807ec2d45a3b011a4c09f6be1d2a5889edcbc5d 15076 
scalapack_2.2.1-3.1.debian.tar.xz
 1309cd6ab8a0b9475e567cb161006838f9d2e5bf 12607 
scalapack_2.2.1-3.1_amd64.buildinfo
Checksums-Sha256:
 712b9db5e5d0450c7b4a87ec8c73f6a045c33890a45468ce0e2d10e6dc62ef3b 2677 
scalapack_2.2.1-3.1.dsc
 16feac08e440167977d99cb58bd4167d86b25ead5c8565cd1d1011637763ce2c 15076 
scalapack_2.2.1-3.1.debian.tar.xz
 d1c132c3eabd3affbb63b77a396c833572a63e4b3f7a2acf2e471bf7bd6e73b7 12607 
scalapack_2.2.1-3.1_amd64.buildinfo
Files:
 49a1a69844ef3044dd34b799e7eed257 2677 devel optional scalapack_2.2.1-3.1.dsc
 cb391417c6ed1539674635e298fdb5c9 15076 devel optional 
scalapack_2.2.1-3.1.debian.tar.xz
 e714b426889f2f9c1947350a50fa0f91 12607 devel optional 
scalapack_2.2.1-3.1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmYHxWwACgkQM2L3AxpJ
kuHOuQ/+NkC9NwxWhxttpiHwQjxuOaOfus0/Ra8SsEOUdRlKLR4yydYRxk2tpHbb
sNqCfvR4zuY3Xa7rv0LHZ0EZ4SqfzDASw+N8B6RRPDpvw9avDqFJRXYy82/UgVBK
Y3amydc8K1clVCeFRc2ZoSM4oRx4+RFPcYgP1JllqeplxhdC5U+HtCbeoSbB4E4W
s82OTq093ORC4H3EXSdqwSTsv6VfA4CJHgmFrRokg8TUuhZ5KeSICD8McBHa6cAe
tE/sVuF7XvCY0I0/0puRoq1LHRbGLnpa6hKPa3WtTvxqeT4Tx1JaNjZeK00rKqEy
kvblk2xmD/dqGCKwy16ZFvQuhmz4jQgubC4ynaQybdtwgzh2f0w8F0A0UzzgLOz4
9kRjVhbGzQ+yoDhY17LeMdar8SY4rQ2ebjZGd2O61/7LBuqHoq1knhhs5qtVCIkl
875B8/MWgJfAr9kYnt8Aukv4hHs/TqMGl0VNVBgAsbWzz1p4c6bp2+AhEG9kQdv5
HlkLoq5cLo+e/dMu4F97IwKh7R6DVrg2qX91YOGYd/33AdvmXFI/iR98H/4YCZlc
+qx6L8zpV8O7ph4wp2voKTo4RhVWdQ8h3cjdmXLOBmSGBi+BKQLleiV0mdIiIkwK
cFCt92lI6LBhP+sGhsow7R1hKgtyxG0kSm63hD2T/XIGqcwG0hY=
=fq03
-END PGP SIGNATURE-



pgp1MkCcrj4h5.pgp
Description: PGP signature

Accepted libkysdk-base 2.2.0.1-1.1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Mar 2024 12:44:02 +0500
Source: libkysdk-base
Architecture: source
Version: 2.2.0.1-1.1
Distribution: unstable
Urgency: medium
Maintainer: kylin Team 
Changed-By: Andrey Rakhmatullin 
Closes: 1066656
Changes:
 libkysdk-base (2.2.0.1-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066656).
Checksums-Sha1:
 988ba96503930630edc91b739abebdfd7ec2a6b1 2165 libkysdk-base_2.2.0.1-1.1.dsc
 2825dc9301eadedc4d501b54ffde0c14c92575f8 4680 
libkysdk-base_2.2.0.1-1.1.debian.tar.xz
 c1b2f769b80fac90a0769ee74a68becdf73b7fc0 15851 
libkysdk-base_2.2.0.1-1.1_amd64.buildinfo
Checksums-Sha256:
 efafbb0e057c8ec9ba9de271197ed4c422c0c5d3a96adb754f065e3410ef3ee4 2165 
libkysdk-base_2.2.0.1-1.1.dsc
 c47f50f5547785e95cd021036d3e1320ee5485959322817b9f6e7473163ed3b5 4680 
libkysdk-base_2.2.0.1-1.1.debian.tar.xz
 b94fc59629dd255b0de0a13f8f335cffc6e798e864f63e3588807eea568ca03a 15851 
libkysdk-base_2.2.0.1-1.1_amd64.buildinfo
Files:
 6b438bfe0b8146ac12ba51d9a81e2223 2165 libs optional 
libkysdk-base_2.2.0.1-1.1.dsc
 805841f1aad5df2da736e3239ca87877 4680 libs optional 
libkysdk-base_2.2.0.1-1.1.debian.tar.xz
 07b4bae9502843d5019675f89b7ad340 15851 libs optional 
libkysdk-base_2.2.0.1-1.1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmYHxTcACgkQM2L3AxpJ
kuEBZBAAj++SpHPZr7cy1fUK4WgPo8kJCu8pRAwBm3UvGR5wRVKZPEXSsFNoiMj6
ampf4HG3WtKhwNvfI5Ng5i1w5BUyZ0Se4cEbh1IprhPRyKwNMgL5h1rvBHrw670m
xrZsZTY/IUm+LkqVVnIrwd4Ezyp87Tdk9GsngOtETOo9br3uULwKYkrnhvCjKmzF
x19teIkFAfLs9sjcxu7quD21TvXJjkUKJ9qdwfuEvc0rb5XxWxDry1lmy69zbFEK
ChmhNdnaNbthUS+rYGeg/JAXK4uKpmLeonXIW0hC0Te+ov1aSHicvj1T3kHCxt6q
oiCeDOvDTYF8hizXXxYkQFpufOOibe1s+O/H5Z9UdS0CnqJQySzwrKjMiUdpE61n
YlLQDuDcas8IHE3rt/BKgFYK531tv45tWTuI/Cb9R7lWugmaxeJ3CGeW4RUFYznD
vrAYH1d4lCaw1Uxq5swqOKLfH5kyNHXM+0TxvOdnI4sqMCf/Vv3Bk05yp63xcg+G
andIDnEZJs2YX3RMRa0I2CxyyI472Hs3twjxGslt7ezwI5JR89Mwb+ugioq6FzIi
rGOHC8X3CizhhPwegtwkItZjTp8spONp/AiFzjqonS3+5XdYU2jrqIZyi5CpImpF
v8pOZskwXIjIGjZn7hJEHvOBU5R3PsXh4iycxCmo9K74Yy5Vijg=
=Lqfi
-END PGP SIGNATURE-



pgpE8LCUUH4aT.pgp
Description: PGP signature