Bug#1101126: ITP: django-distill -- Static site generator and publisher for Django

[Teemu Hukkanen]

Package: wnpp
Severity: wishlist
Owner: Teemu Hukkanen 
X-Debbugs-Cc: debian-devel@lists.debian.org

  Package name: python3-django-distill
  Version : 3.2.7
  Upstream Contact: meeb 
  URL : https://github.com/meeb/django-distill/
  License : MIT
  Programming Lang: Python
  Description : Static site generator and publisher for Django

 Django-distill extends existing Django sites with the ability to export
 fully functional static sites. It is suitable for sites such as blogs that have
 a mostly static front end but you still want to use a CMS to manage the
 content.

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

[Robert Edmonds]

Guillem Jover wrote:
> Hi!
> 
> A recent dupload improvement to switch from its GnuPG based OpenPGP
> verification hook to use the dpkg OpenPGP multi-backend
> implementation, which as a side effect got rid of a very old code path
> that was ignoring some GnuPG verification failures, resurfaced an old
> known problem with OpenPGP certificates with SHA-1 issues in the
> Debian keyrings.
> 
> Not all of these issues are equally "bad" from a Debian point of view,
> but all are probably bad for the certificate owners, as it might imply
> that people cannot verify signatures made with those certificates. In
> the Debian context that might mean emails, or signatures on artifacts
> such as .dsc or .changes. Depending on the specific problem those
> might even cause rejects from DAK.
> 
> I filed #1100734 against debian-keyring the other day, but to try to
> help people that might get confused by the kind or errors that dupload
> (or dpkg-source --require-valid-signature or dscverify) might be
> emitting (I think dput-ng is strict with its OpenPGP verification and
> should have already been rejecting signatures from those certificates,
> although I think dput might be lenient as dupload used to be and might
> let those through (?)), I've prepared a list of affected certificates
> per keyring, which I'm attaching.
> 
> To check for the exact issues you can use the Sequoia certificate
> linter (from the «sq» package) with something like:
> 
>   $ sq cert lint --cert FINGERPRINT
> 
> To fix your certificate it should (in theory) be enough to do:
> 
>   $ sq cert lint --cert FINGERPRINT --fix | gpg --import
> 
> (Given that Sequoia can transparently read from the GnuPG certstore,
> and talk to gpg-agent.)
> 
> You might want to check the chapter for that at
> . If you'd prefer to use GnuPG
> to fix your certificate, although in a really more tedious way, you can
> follow these instructions instead:
> 
>   
> https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
> 
> (I'm also attaching the script I used to generate the lists.)
> 
> Thanks,
> Guillem

>   Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE
>UserID: Robert Edmonds 
>UserID: Robert Edmonds 
>UserID: Robert Edmonds 

Hello,

I'm not sure this analysis is completely correct. As far as I can tell,
you've flagged my key on the basis of "sq cert lint" reporting the
following output:

$ sq cert lint --keyring /usr/share/keyrings/debian-keyring.gpg --cert 
01817AB0AAF6CDAE
Certificate 01817AB0AAF6CDAE, key 292C9BB54A4D3CBA uses a SHA-1-protected 
binding signature.
Examined 1 certificate.
  0 certificates are invalid and were not linted. (GOOD)
  1 certificate was linted.
  1 of the 1 certificates (100%) has at least one issue. (BAD)
0 of the linted certificates were revoked.
  0 of the 0 certificates has revocation certificates that are weaker than 
the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User 
ID:
  0 have at least one User ID protected by SHA-1. (GOOD)
  0 have all User IDs protected by SHA-1. (GOOD)
1 of the non-revoked linted certificates has at least one non-revoked, live 
subkey:
  1 has at least one non-revoked, live subkey with a binding signature that 
uses SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked, 
live, signing-capable subkey:
  0 certificates have at least one non-revoked, live, signing-capable 
subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)

  Error: 1 certificate have at least one issue

Now, key 292C9BB54A4D3CBA is my encryption subkey, not the main key
01817AB0AAF6CDAE that is used for signing and certifying:

sec  rsa4096/01817AB0AAF6CDAE
 created: 2013-10-03  expires: never   usage: SC
 card-no: 0005 3A89
 trust: ultimate  validity: ultimate
ssb  rsa4096/292C9BB54A4D3CBA
 created: 2013-10-03  expires: never   usage: E
 card-no: 0005 3A89

Since only the encryption subkey is affected, I do not believe this
problem can affect the signatures on my signed .dsc or .changes files.

Here are the raw PGP packets, from a clean sid chroot with gpg and
debian-keyring installed:

root@7311057f397a:/# gpg --keyring=/usr/share/keyrings/debian-keyring.gpg 
--export-options export-minimal --export 01817AB0AAF6CDAE | gpg --list-packets
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1380802569, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 01817AB0AAF6CDAE
# off=528 ctb=b4 tag=13 hlen=2 plen=31
:user ID packet: "Robert Edmonds "
# off=561 ctb=89 tag=2 hlen=3 plen=543
:signature packet: algo 1, keyid 01817AB

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Tobias Frost]

Hallo Andreas,

(this should probably go to vote as general questions for the candiates,
but I'm not having enought time right now to pursue this.)

On Thu, Mar 20, 2025 at 03:36:48PM +0100, Andreas Tille wrote:
> Hi Robert,
> 
> Am Sat, Mar 15, 2025 at 04:34:09PM -0400 schrieb Roberto C. Sánchez:
> > Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
> > for a package?
> 
> I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS.

How do you define "*uncoordinated*" NMUs?
What makes it "not uncoordinated" in your view?

> > * Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
> >   wishlist bugs for packaging a new upstream version, but care should
> >   be taken to minimize the impact to the maintainer.) Fixing cosmetic
> >   issues or changing the packaging style in NMUs is discouraged.
> > 
> > I had thought of possibly suggesting an update to the documentation, but
> > I'm not sure that adding more words would make the matter any more
> > clear.
> 
> I'd like to stir some constructive discussion about this-hopefully
> leading to a procedure that is acceptable to everyone and can be
> finalized for discussion at DebCamp.

Andreas, the this is the correct approach. First discuss changes and
then implement them when project consensus has been reached.

Do you agree on this principle on the how to work together in Debian?

Unfortunatly1 I have to ask this question, as this is not how you and
(your|the) salvaging team is operating at the moment - IMHO.

I acknowledge, while -- after being scoulted -- the approach how to
handle ITS' by the team has changed, it continues to move or create
repos of projects it "handles" to git repos and now doing NMUs instead.
That often happens without any "coordination", for example, I've just
got a message that ddate has been moved to the debian group on salsa,
and the changelog mentions an NMU. (However, another NMU was faster and
now the repo at salsa.d.o does not reflect the package state.)
There is *no* bug report against ddate announcing any NMU, and no
nmudiff.

The move to the debian namespace changes (semantics of) maintainership,
which is bad and *not the purpose of NMUs*

The move to the debian namespace cannot be easily undone, as those repos
are protected and require an salsa admin to act on e.g for (re)moving
it. 

So, do you agree that such fudamental changes to our procedure should
be discussed before? Do you think that the established rules should be
followed until then?

> > How do others suggest to handle this particular situation?
> 
> I support issuing a warning before performing an NMU. These NMUs should
> only apply to packages that have not been uploaded by their maintainer
> for at least five years (more than two releases) and should meet
> additional criteria, which I'd like to define together with your input.
> 
> If there is no response within 21 days (aligning with the ITS process
> timeline), an NMU to delayed=10 based on a repository on Salsa should be
> acceptable. The key rationale is to ensure that the history of NMUs is
> properly recorded. 

The history of an NMU is recorded in the archives, this is the
canonical location.

Looking at nstream, currently in DELAYED/8, there is no bug report
against the package that you are NMUing, and there is no nmudiff filed
against the project. And it also moves the repository to the debian and
many changes are not addressing (filed) bugs.

(IMHO this is not within the (current) NMU procedures we have.)

> 
> The following example brought this to my mind: The package pccts[1] has
> been NMUed four times in a row, with the last maintainer upload dating
> back to 2010.
> 
> I reported the maintainer to the MIA team, as this is their only package
> and I have seen no activity from them. So far, I have closed five bugs
> and updated the packaging to the latest standards. However, there are
> still unresolved issues, and I would like to invite others to contribute
> to this effort. Maintaining the package in Git would be essential to
> continue this work effectively.

Do you think Debians approach to how being a member should be changed,
especially in the light that there are inactive members.
What changes would you think are necessary? How would you reform the MIA
procedures?

> To address this, I opened a bug with the proposed warning[2]. What do
> you think about this as a first experiment to determine what is
> acceptable and what is not?

Why do you think the procedures we have for NMUs are not sufficient?
Why do you think that you can invent an ITN without prior discussion?

> What do you think?

> Kind regards
> Andreas.
> 
> 
> [1] https://tracker.debian.org/pkg/pccts
> [2] https://bugs.debian.org/1100859
> 
> -- 
> https://fam-tille.de
> 


signature.asc
Description: PGP signature

Bug#1101100: ITP: python-argon2-cffi-bindings -- Low-level CFFI bindings for Argon2

[Carl Keinath]

Package: wnpp
Severity: wishlist
Owner: Carl Keinath 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-argon2-cffi-bindings
  Version : 21.2.0
  Upstream Contact: Hynek Schlawack 
* URL : https://github.com/hynek/argon2-cffi-bindings
* License : MIT
  Programming Lang: Python
  Description : Low-level CFFI bindings for Argon2

This package provides low-level CFFI bindings to the Argon2 
password hashing algorithm implementation. It is intended as
a backend for higher-level libraries, mainly argon2-cffi. 
It exposes the ffi and lib interfaces.

Further information:
* The package will be configured to link against the systems 
  libargon2 when built with ARGON2_CFFI_USE_SYSTEM=1.
* Latest version of python-argon2 depends on the bindings.
  Older releases provided the bindings within the package.

I intend to maintain this package as part of the Debian Python Team,
however as of now I am awaiting approval.

The initial upload will be targeted to experimental and migrate
to unstable after trixie release.

Best,
Carl Keinath

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Otto Kekäläinen]

Hi,

> Unfortunatly1 I have to ask this question, as this is not how you and
> (your|the) salvaging team is operating at the moment - IMHO.
>
> I acknowledge, while -- after being scoulted -- the approach how to
> handle ITS' by the team has changed, it continues to move or create
> repos of projects it "handles" to git repos and now doing NMUs instead.
> That often happens without any "coordination", for example, I've just
> got a message that ddate has been moved to the debian group on salsa,
> and the changelog mentions an NMU. (However, another NMU was faster and
> now the repo at salsa.d.o does not reflect the package state.)
> There is *no* bug report against ddate announcing any NMU, and no
> nmudiff.

This includes a bunch of accusations, so let's first check if they are
actually true. I haven't reviewed a large number of packages that have
been salvaged recently, but I did check the context for ddate[1],
pccts[2] and nstreams[3].

In the case of ddate there was a bug, and two people updated that
package on a place that was not the original version control of that
package, and neither announced their intent in the BTS either, so they
ended up doing duplicate work. It didn't have neither an TS nor NMU
email/bug report. I don't think it is fair to accuse Andreas of what
two other people did on their own, without following any process.

Only pccts and nstreams showcase what Andreas is doing, and in them he
filed Bug#1100859 and Bug#1089721, announcing his intent in advance,
which seems to me as a very thorough description and solid
communication. For nstreams the maintainer didn't reply anything, so
Andreas proceeded to move the package to the shared namespace on
Debian, where multiple people was able to collaborate on what changes
to commit before upload, and seems he then uploaded it in the DELAYED
queue for one last chance for the original maintainer to react.

What happened for ddate is unfortunate, and could maybe have been
prevented if either person working of the package had announced
something in the BTS, but I don't think it is an example of the work
of salvaging packages is currently systematically wrong or
uncoordinated or not discussed. Your reference to being scoulted
indicates that there was probably something more to this, and what you
actually experienced being wrong or unfair was perhaps left out from
the email. Thus I can't comment the bigger picture, but I would ask to
refrain from throwing out accusations on one person for trying to
create a process if the accusations are based on two other people
doing something that wasn't that process.


[1] https://tracker.debian.org/pkg/ddate
[2] https://tracker.debian.org/pkg/pccts
[3] https://tracker.debian.org/pkg/nstreams

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

[Guillem Jover]

Hi!

On Sun, 2025-03-23 at 18:46:37 -0400, Robert Edmonds wrote:
> Guillem Jover wrote:
> > Not all of these issues are equally "bad" from a Debian point of view,
> > but all are probably bad for the certificate owners, as it might imply
> > that people cannot verify signatures made with those certificates. In
> > the Debian context that might mean emails, or signatures on artifacts
> > such as .dsc or .changes. Depending on the specific problem those
> > might even cause rejects from DAK.
[…]
> > To check for the exact issues you can use the Sequoia certificate
> > linter (from the «sq» package) with something like:
[…]

> >   Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE
> >UserID: Robert Edmonds 
> >UserID: Robert Edmonds 
> >UserID: Robert Edmonds 

> I'm not sure this analysis is completely correct. As far as I can tell,
> you've flagged my key on the basis of "sq cert lint" reporting the
> following output:
> 
> $ sq cert lint --keyring /usr/share/keyrings/debian-keyring.gpg --cert 
> 01817AB0AAF6CDAE
> Certificate 01817AB0AAF6CDAE, key 292C9BB54A4D3CBA uses a SHA-1-protected 
> binding signature.
> Examined 1 certificate.
>   0 certificates are invalid and were not linted. (GOOD)
>   1 certificate was linted.
>   1 of the 1 certificates (100%) has at least one issue. (BAD)
> 0 of the linted certificates were revoked.
>   0 of the 0 certificates has revocation certificates that are weaker 
> than the certificate and should be recreated. (GOOD)
> 0 of the linted certificates were expired.
> 1 of the non-revoked linted certificate has at least one non-revoked User 
> ID:
>   0 have at least one User ID protected by SHA-1. (GOOD)
>   0 have all User IDs protected by SHA-1. (GOOD)
> 1 of the non-revoked linted certificates has at least one non-revoked, 
> live subkey:
>   1 has at least one non-revoked, live subkey with a binding signature 
> that uses SHA-1. (BAD)
> 0 of the non-revoked linted certificates have at least one non-revoked, 
> live, signing-capable subkey:
>   0 certificates have at least one non-revoked, live, signing-capable 
> subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
> 
>   Error: 1 certificate have at least one issue

> Since only the encryption subkey is affected, I do not believe this
> problem can affect the signatures on my signed .dsc or .changes files.

> I do not see any of the verification failures that you demonstrated
> downthread on debian-devel when I try to verify a recent upload of mine:

Sure, see the quoted text above from my original mail, perhaps I should
have been more explicit, or perhaps list more cases. There are other
cases for example where the SHA-1 issues are only over userids that are
not being used to sign artifacts in Debian. But I still though it would
be helpful to notify people of any problem that might affect them in
other contexts (and it made the reporting easier as well :).

> The "gpg --edit-key" instructions on the lore.kernel.org page you
> linked did not work for me. (I use an OpenPGP hardware card and have not
> investigated Sequoia's support for hardware keys.)
> 
> I did find this blog post:
> 
> https://blog.bmarwell.de/2020/11/21/fixing-old-sha1-infested-openpgp-keys.html
> 
> And the command "gpg --quick-set-expire  0 '*'" listed
> on that page worked to replace the self-signature on the encryption
> subkey. Now I have the following signature packet with "digest algo 10"
> (SHA-512) rather than "digest algo 2" (SHA-1):
> 
> # off=2850 ctb=89 tag=2 hlen=3 plen=566
> :signature packet: algo 1, keyid 01817AB0AAF6CDAE
>   version 4, created 1742767476, md5len 0, sigclass 0x18
>   digest algo 10, begin of digest 93 60
>   hashed subpkt 27 len 1 (key flags: 0C)
>   hashed subpkt 33 len 21 (issuer fpr v4 
> DF3D96EEB3827820F302665C01817AB0AAF6CDAE)
>   hashed subpkt 2 len 4 (sig created 2025-03-23)
>   subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
>   data: [4095 bits]

Ah, thanks for the info, we can probably put this in a future FAQ or
similar, then!

I don't use an OpenPGP hardware card so I never had to look how to use
that, but I do recall reading in the past that this should be currently
supported by Sequoia-PGP (I think in theory even out of the box, but
perhaps not if the keys are in the GnuPG keystore/gpg-agent, but
dunno. There's also the openpgp-card-state package). In any case I'll
ask around, if only to at least be able to give better help/guidance
(or to provide a better FAQ entry).

> With this new signature, the "sq cert lint" command does not print any
> red text to the terminal now.

Great! :)

Thanks,
Guillem

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Jonas Smedegaard]

Quoting Otto Kekäläinen (2025-03-23 23:54:59)
> > Unfortunatly1 I have to ask this question, as this is not how you and
> > (your|the) salvaging team is operating at the moment - IMHO.
> >
> > I acknowledge, while -- after being scoulted -- the approach how to
> > handle ITS' by the team has changed, it continues to move or create
> > repos of projects it "handles" to git repos and now doing NMUs instead.
> > That often happens without any "coordination", for example, I've just
> > got a message that ddate has been moved to the debian group on salsa,
> > and the changelog mentions an NMU. (However, another NMU was faster and
> > now the repo at salsa.d.o does not reflect the package state.)
> > There is *no* bug report against ddate announcing any NMU, and no
> > nmudiff.
> 
> This includes a bunch of accusations, so let's first check if they are
> actually true. I haven't reviewed a large number of packages that have
> been salvaged recently, but I did check the context for ddate[1],
> pccts[2] and nstreams[3].

[details snipped not disputing that NMUs occured instead of salvaging]

I find it quite relevant to raise concerns when the distinction between
NMU and slavaging gets blurred.

We have a documented process for doing non-maintainer uploads to a
package, which includes narrowly targeted changes not fundamentally
changing the way the package is maintained - even if the maintainer is
totally unresponsive.

We have a documented process for salvaging a package, which includes
the major action of taking over as maintainer even if the current
maintainer is unresponsive.

In our defined processes for NMUs and salvaging, we make sure to not
tell the maintainer how to do their work: An NMU should be narrow in
scope, and if it turns out to "blow up" then it is the responsibility
of the NMUer to fix collateral work. Salvaging puts the burden fully
in the hands of the person taking over the maintenance, who can then
restructure as they pleases, *after* the salvaging process has
completed.

I consider it an abuse of the NMU process to restructure maintenance
workflow of the package - e.g. by declaring or changing a certain use
of VCS for it. I find such abuse problematic, because it puts a burden
on the maintainer for how they ought to do their work from then on.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[G. Branden Robinson]

[Summary: Let's permit ourselves to evolve, collectively _and_
individually, instead of seeking a winning workflow to freeze.]

Hi Otto,

At 2025-03-22T20:36:32-0700, Otto Kekäläinen wrote:
> > > Just out of curiosity, what email client and plugins do you use to
> > > achieve your optimal email-based workflow?
> >
> > I don't see where Wookey made a claim that his workflow was
> > "optimal", merely that it was effective for him personally.  Debian
> > Developers are a diverse bunch and approach packaging with a variety
> > of techniques.
> >
> > Not everyone will work exactly as another does; we shouldn't expect
> > that.  In high-dimensional spaces, a global optimum often doesn't
> > exist.
> 
> That is why I wrote "your optimal". It was an honest question about
> what setup somebody has.

I may have been too subtle in my attempt at brevity.  Part of my point
is that Wookey's workflow might not be optimal _even for him_.  He could
discover a tool or technique tomorrow that makes his life easier.  I
think this true of practically all of us.  (And it's not necessarily
the same tools or techniques that will improve each person's process.)

> There is no need to start stating the obvious about people being
> different.

I think it's worth restating when threads like

https://lists.debian.org/debian-devel/2024/07/msg00429.html

linger in recent memory.

> Stating that one global optimum probably does not exist is also rather
> obvious.

To those trained in mathematics, maybe.  Many people aren't.

> At the same time it can still be true that for many isolated
> repetitive Debian packaging tasks a global optimum can most likely be
> found with some effort.

"Most likely"?  By what technique did you compute your P >> 0.5?

It's fine if you're personally confident that it's the case.  But if you
don't support a quantitative claim, don't make one (even non-numeric
ones, like "most", "few", "always", or "never") without at least hinting
at some source of evidence usable for reaching independent conclusions.

> Regardless if a global optimum can be achieved or not, we need to tell
> new aspiring Debian Developers something when they ask how to do
> things, and that advice needs to be something that is compatible
> enough with everyone else to make contributions valuable. Hence asking
> what workflows others have is a perfectly valid question and a good
> topic for discussion.

I agree; we should encourage developers to explore and experiment with
workflows (within the boundaries of their responsibilities).  It's not
necessary for each individual to focus on the search for the One
Workflow To Rule Them All; if such a thing exists, I think it will
reveal itself organically through converging preferences.  Labor-saving
devices are attractors in this chaotic space.

Regards,
Branden


signature.asc
Description: PGP signature