Bug#1059251: ITP: node-git-url-parse -- High level git url parser for common git providers

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-git-url-parse
  Version : 13.1.1
  Upstream Author : Ionică Bizău  
(https://ionicabizau.net)

* URL : https://github.com/IonicaBizau/git-url-parse
* License : Expat
  Programming Lang: JavaScript
  Description : High level git url parser for common git providers

 A high level git url parser for common git providers.

 This package is part of my effort to package yarnpkg for Debian.
 Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059248: ITP: python-cirpy -- Python interface for the Chemical Identifier Resolver (CIR)

[Yogeswaran Umasankar]

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

* Package name: python-cirpy
  Version : 1.0.2
  Upstream Contact: Matt Swain 
* URL : https://github.com/mcs07/CIRpy
* License : Expat
  Programming Lang: Python
  Description : Python interface for the Chemical Identifier Resolver (CIR)

CIRpy is a Python interface for the Chemical Identifier Resolver (CIR)
by the CADD Group at the NCI/NIH. It is a web service that will resolve
any chemical identifier to another chemical representation. It is a
great tool for bio-informatics and chemistry.

Re: Reaction to potential PGP schism

[Cyril Brulebois]

Hi Daniel,

Quick backstory: I stayed away from hardware crypto for a long while
since there were so many incompatibilities, partial support, or side
patches to get basic things to work. Over time, it seems it got to a
point where it's mainstream enough that you can buy a Yubikey without
much of a second thought, and get GPG to work out of the box on it…

Daniel Kahn Gillmor  (2023-12-20):
> OpenPGP implementations have generally learned from those failures, and
> many of them are now much more resilient and can support the kinds of
> upgrade path that we need to consider.  For most of our
> signing/verifying-focused work, that means:
> 
>  - verifying tools should ignore signatures and certificates that they
>don't understand, while still validating signatures from certificates
>that they do understand
> 
>  - signing tools can make pairs of signatures, one "compatibility"
>signature and one "modern" signature
> 
> This means that for a debian signing/verification context, like package
> distribution, which has a global workflow, starting from an existing
> OpenPGP implementation, signing key and corresponding verification
> certificate, it looks like:
> 
>  0) upgrade the signing tool, and start upgrading some of the
>  verification tooling.
> 
>  1) create a new signing certificate with the new version, algorithm, or 
> feature.
> 
>  2) distribute the old+new certificates for the verifiers.
> 
>  3) make signatures with old+new in parallel
> 
>  4) complete upgrade of all verification tooling
> 
>  5) stop making signatures with old signing certificates

… what does this mean for anything that involves hardware-backed crypto?
I'm thinking Yubikeys and the like, but also HSMs that might be on the
critical path to sign things like GRUB, linux (at least for now), etc.

Even if we end up with a brand new gnupg release on the relevant signing
host(s), I fear hardware devices might not feature all the bits that are
needed for those new features?


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


signature.asc
Description: PGP signature

Bug#1059240: ITP: python-chemspipy -- A way to interact with ChemSpider in Python

[Yogeswaran Umasankar]

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

* Package name: python-chemspipy
  Version : 2.0.0
  Upstream Contact: Matt Swain 
* URL : https://github.com/mcs07/ChemSpiPy
* License : Expat
  Programming Lang: Python
  Description : A way to interact with ChemSpider in Python

ChemSpiPy provides a way to interact with ChemSpider in Python. It
allows chemical searches, chemical file downloads, depiction and
retrieval of chemical properties. It can be widely used in both
chemistry and bio-informatics.

Re: Reaction to potential PGP schism

[Daniel Kahn Gillmor]

Hi Gioele--

On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote:
> On 21/12/23 04:16, Daniel Kahn Gillmor wrote:
> As the Uploader of rust-sequoia-openpgp, what do you think of the 
> related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg 
> that uses sequoia internally)?
>
> Would it work as a stop-gap measure while the Debian infrastructure 
> moves from GnuPG to something else (to `sop`, for instance)?
>
> [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in 
> Debian AFAIK

Thanks for pointing this out!  It looks interesting, but i've never used
it (or even tested it) myself.  I don't think it can be a completely
perfect, feature-for-feature replacement for GnuPG, given the
overwhelming complexity and peculiarity of the GnuPG interface, but I
imagine it would work for some people, for some purposes.

I certainly wouldn't object to anyone packaging it for debian as long as
it ships its binary interface someplace other than /usr/bin/gpg.  Modulo
dealing with the rust dependencies, that seems like an obviously
reasonable and straightforward thing to try to do.

I don't know how the "chameleon" would compare with GnuPG itself in
terms of performance or some of the scaling concerns i mentioned in my
earlier e-mail, but such a straightforward deployment should make it
easy to test.

If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users.  This
would be the kind of thing that the experimental archive is designed
for.

One of the ongoing challenges with GnuPG development is the fear of
dropping or mis-handling some feature or flag or option or configuration
that someone has stuffed into some script somewhere and completely
forgotten about.  GnuPG itself deals with this kind of problem
regularly, and sometimes things like this do break during an upgrade.
Clawing the way back from such a break actually ends up making the
interface even more complex and surprising to those people who haven't
seen how it accreted in the first place :/ It was scary enough to change
/usr/bin/gpg to move from the 1.4 branch to the 2.x branch many years
ago (we shipped the 2.0 branch as /usr/bin/gpg2, and only finally made
/usr/bin/gpg update when the 2.1.x branch was sufficiently mature). And
even thenm we dealt with the fallout from that change for years
(e.g. see /usr/bin/migrate-pubring-from-classic-gpg in the gnupg-utils
package).  The differences were enough that I resisted using
/etc/alternatives to let each installation decide which package offered
/usr/bin/gpg1, because of the dangerous side effects of switching back
and forth (see #806904 for example, and the conversations at DebConf14).
I can only imagine that trying to ship the "chameleon" as /usr/bin/gpg
would face some of the same challenges, probably even more severely.

At best, something like this would be a stop-gap, as you say.  i
wouldn't want the long-term health of *PGP functionality in debian to
depend specifically on the command-line interface for /usr/bin/gpg,
regardless of who is implementing it.  Even GnuPG upstream appears to
agree with this sentiment, as they encourage programmatic users of GnuPG
to use libgpgme, which is supposed to hide some of the command-line
complexity.

  --dkg


signature.asc
Description: PGP signature

Re: /usr-move: Do we support upgrades without apt?

[David Kalnischkies]

On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote:
> On 21/12/2023 09:41, Helmut Grohne wrote:
> > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > using apt unsupported until we no longer deal with aliasing?
> 
> I incline towards "no"; if an upgrade has failed part-way (as does happen),
> people may then reasonably use dpkg directly to try and un-wedge the upgrade
> (e.g. to try and configure some part-installed packages, or try installing
> some already-downloaded packages).

You can configure half-installed packages, no problem, this is about
unpacking (which is the first step in an install, where only Conflicts
and Pre-Depends matter, if you are not deep into dpkg vocabulary)


The "try installing" part is less straight forward. In general, you
are running into dpkg "features" (e.g. not handling pre-depends) or
into dpkg bugs (e.g. #832972, #844300): In the best case your system
state became a bit worse and hence harder to "un-wedge". In the worst
case a maintainer script has run amok as nobody tested this.
But yeah, most of the time you will indeed be lucky and hence come to
the unreasonable conclusion that its reasonable to call dpkg directly.


Anyway, if your upgrade failed part-way, you are probably in luck given
that its more likely the upgrade failed in unpack/configure than in
removal – so if you aren't too eager to install more packages by hand
but limit yourself to e.g. (re)installing the ones who failed you are
fine as apt will have removed the conflictors already for you (or
upgraded them, if that can resolve the conflict).


But lets assume you are not:
As you are driving dpkg by hand you also have the time to read what it
prints, which in the problematic case is (as exampled by #1058937):
| dpkg: considering removing libnfsidmap-regex:amd64 in favour of 
libnfsidmap1:amd64 ...
| dpkg: yes, will remove libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64
(and the same for libnfsidmap2:amd64 as well. If your terminal supports
 it parts of these messages will be in bold)

Note that the similar "dpkg: considering deconfiguration of …" which is
the result of Breaks relations is not a problematic case.

(Also note that this exact situation is indeed another reason why
 interacting with dpkg by hand is somewhat dangerous as you might not
 expect packages to be removed from your system while you just told
 dpkg to unpack something… just remember that the next time you happen
 to "dpkg -i" some random deb file onto your system.)

That is of course no hint that a file might have been lost due to
aliasing if you don't know that this could be the case, but on the
upside it is not entirely a silent file lose situation either. We could
write something in the release notes if someone happens to read them AND
also encounters this message.


Query your memory: Did you encounter this message before? Nothing in
the /usr merge plan makes that particularly more likely to be encountered
for a user and not all of the encounters will actually exhibit the file
lose. So if you haven't – and I would argue that most people haven't –
there is a pretty good chance you wont have a problem in the future
either…


So, in summary: Yes, there are theoretic relatively easy ways to trigger
it with dpkg directly. That isn't the question. The question is if a real
person who isn't actively trying to trigger it is likely to run into it
by accident (and/or if such a person can even reasonably exist) so that
we have to help them by generating work for many people and potentially
new upgrade problems for everyone – or if we declare them, existing or
not, a non-issue at least for the upgrade to trixie.


And on a sidenote: I would advise to reconsider interacting with dpkg
too casually – but luck is probably on your side in any case.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: /usr-move: Do we support upgrades without apt?

[David Kalnischkies]

On Thu, Dec 21, 2023 at 03:31:55PM +0100, Marc Haber wrote:
> On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote:
> > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> > > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > > using apt unsupported until we no longer deal with aliasing?
> > 
> > I think so, yes. I don't think it's likely that there are people doing
> > upgrades on running systems not using apt.
> 
> Do those GUI frontends that work via packagekit or other frameworks
> count as "using apt"?

I explained that in full detail in my mail to the pause-thread:
https://lists.debian.org/debian-devel/2023/12/msg00039.html

In short: helmuts "apt" (my "APT") includes everything that uses libapt.
That is apt, apt-get, python-apt, aptitude, synaptics, everything based
on packagekit, …

I know of only cupt and dselect which don't count, but I have some
suspicion that they would work anyhow. IF you don't run into other
problems with them, like that they do not implement Multi-Arch.


So this thread is really about:
How much are people REALLY fiddling with dpkg directly in an upgrade
and can we just say its unsupported – because, at least that is my view,
in practice nobody does it and its therefore also completely untested.

Case in point: We have this thread not because someone found it while
working with dpkg directly even through they had potentially years, but
because Helmut ended up triggering an edge case in which apt interacts
with dpkg in this way and only after that people looked for how to
trigger it with dpkg because triggering it with apt is hard (= as Helmut
checked, no package (pair) in current unstable is known to exhibit the
required setup).

(I will write another mail in another subthread about the finer details
 of what interacting with dpkg in an upgrade means and what might be
 problematic if you aren't careful – in general, not just with aliasing)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: /usr-move: Do we support upgrades without apt?

[Michael Biebl]

Am 21.12.23 um 11:50 schrieb Christoph Berg:

Re: Helmut Grohne

Is it ok to call upgrade scenarios failures that cannot be reproduced
using apt unsupported until we no longer deal with aliasing?

If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug)
with no action calling the scenario unsupported.


I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.


A (dist-)upgrade not using apt is very much a corner case/niche use case.

I'd be interested if #1058937 can be reproduced using aptitude, though.
While the release notes explicitly recommend using apt/apt-get, I do 
think that dist-upgrades using aptitude should not run into those file 
loss issues.


If aptitude is safe, I'd consider #1058937 a bug, that is not release 
critical and I'd assign low(er) priority to it.
Other issues, like getting all packages updated to move their files to 
/usr, have higher priority.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059231: ITP: qt6-location -- Qt6 Location

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: qt6-location
  Version : 6.6.1
  Upstream Contact: The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL, LGPL, FDL
  Programming Lang: C++
  Description : Qt6 Location

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

The Qt Location module helps you create mapping solutions using data
available from popular location service providers, such as Open Street Map.

Re: /usr-move: Do we support upgrades without apt?

[Simon Richter]

Hi,

On 21.12.23 23:19, Antonio Terceiro wrote:


I think so, yes. I don't think it's likely that there are people doing
upgrades on running systems not using apt.


What about aptitude and the various other frontends, like the DBus based 
package management tools? I'd expect quite a few people to use these for 
upgrades (I will certainly use aptitude).


FWIW, I've made some progress with my dpkg patches, the attached log is 
the relevant snippet from running the tests[1]. It's still far from 
complete though.


   Simon

[1] https://salsa.debian.org/sjr/dpkg/-/pipelines
/usr/bin/make -C t-file-conflicts-usrmerge test
make[1]: Entering directory '/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge'
mkdir -p \
pkg-usrmerge/usr/lib64 \
pkg-usrmerge/usr/libx32 \
pkg-usrmerge/usr/lib32 \
pkg-usrmerge/usr/sbin \
pkg-usrmerge/usr/bin
touch stamp-empty-directories
dpkg-deb  -b pkg-usrmerge pkg-usrmerge.deb
dpkg-deb: building package 'pkg-usrmerge' in 'pkg-usrmerge.deb'.
dpkg-deb  -b pkg-a pkg-a.deb
dpkg-deb: building package 'pkg-a' in 'pkg-a.deb'.
dpkg-deb  -b pkg-b pkg-b.deb
dpkg-deb: building package 'pkg-b' in 'pkg-b.deb'.
env 
PATH=/builds/sjr/dpkg/src:/builds/sjr/dpkg/utils:/builds/sjr/dpkg/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  DPKG_DATADIR="/builds/sjr/dpkg/src"  dpkg 
--admindir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkgdb" 
--force-script-chrootless --force-not-root  --force-unsafe-io 
--instdir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkginst" 
--no-debsig --log=/dev/null  -P pkg-a pkg-b pkg-usrmerge
dpkg: warning: ignoring request to remove pkg-a which isn't installed
dpkg: warning: ignoring request to remove pkg-b which isn't installed
dpkg: warning: ignoring request to remove pkg-usrmerge which isn't installed
env 
PATH=/builds/sjr/dpkg/src:/builds/sjr/dpkg/utils:/builds/sjr/dpkg/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  DPKG_DATADIR="/builds/sjr/dpkg/src"  dpkg 
--admindir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkgdb" 
--force-script-chrootless --force-not-root  --force-unsafe-io 
--instdir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkginst" 
--no-debsig --log=/dev/null  -i pkg-a.deb pkg-b.deb
Selecting previously unselected package pkg-a.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack pkg-a.deb ...
Unpacking pkg-a (0) ...
Selecting previously unselected package pkg-b.
Preparing to unpack pkg-b.deb ...
Unpacking pkg-b (0) ...
Setting up pkg-a (0) ...
Setting up pkg-b (0) ...
#
# test if usrmerge fails because it introduces a conflict
#
! env 
PATH=/builds/sjr/dpkg/src:/builds/sjr/dpkg/utils:/builds/sjr/dpkg/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  DPKG_DATADIR="/builds/sjr/dpkg/src"  dpkg 
--admindir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkgdb" 
--force-script-chrootless --force-not-root  --force-unsafe-io 
--instdir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkginst" 
--no-debsig --log=/dev/null  -i pkg-usrmerge.deb
Selecting previously unselected package pkg-usrmerge.
(Reading database ... 6 files and directories currently installed.)
Preparing to unpack pkg-usrmerge.deb ...
+ dpkg-alias --package usrmerge --add /bin /usr/bin
(Reading database ... 6 files and directories currently installed.)
dpkg: error processing archive pkg-usrmerge.deb (--install):
 new pkg-usrmerge package pre-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 pkg-usrmerge.deb
env 
PATH=/builds/sjr/dpkg/src:/builds/sjr/dpkg/utils:/builds/sjr/dpkg/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  DPKG_DATADIR="/builds/sjr/dpkg/src"  dpkg 
--admindir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkgdb" 
--force-script-chrootless --force-not-root  --force-unsafe-io 
--instdir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkginst" 
--no-debsig --log=/dev/null  -P pkg-a pkg-b pkg-usrmerge
(Reading database ... 6 files and directories currently installed.)
Removing pkg-a (0) ...
Removing pkg-b (0) ...
dpkg: warning: ignoring request to remove pkg-usrmerge which isn't installed
env 
PATH=/builds/sjr/dpkg/src:/builds/sjr/dpkg/utils:/builds/sjr/dpkg/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  DPKG_DATADIR="/builds/sjr/dpkg/src"  dpkg 
--admindir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkgdb" 
--force-script-chrootless --force-not-root  --force-unsafe-io 
--instdir="/builds/sjr/dpkg/tests/t-file-conflicts-usrmerge/../dpkginst" 
--no-debsig --log=/dev/null  -i 

Re: /usr-move: Do we support upgrades without apt?

[Simon McVittie]

On Thu, 21 Dec 2023 at 15:31:55 +0100, Marc Haber wrote:
> Do those GUI frontends that work via packagekit or other frameworks
> count as "using apt"?

Managing apt/dpkg packages via packagekit uses libapt-pkg6.0 (via
/usr/lib/*/packagekit-backend/libpk_backend_apt.so). I don't know whether
that's enough to give it the specific desirable behaviour around Conflicts
that Helmut is referring to, but I hope it is.

Other non-CLI package management like unattended-upgrades is generally
in a similar situation, using libapt-pkg or its language bindings,
but not the apt(8) or apt-get(8) CLIs specifically.

smcv

Re: /usr-move: Do we support upgrades without apt?

[Simon Richter]

Hi,

On 21.12.23 23:31, Marc Haber wrote:


Do those GUI frontends that work via packagekit or other frameworks
count as "using apt"? I now that WE recommend using apt in a text
console outside of X, but even many of our own users do what their
Desktop Environment does, and our downstreams like *b*nt* recommend
other ways to upgrade as well.


Oof, which reminds me: if you run nVidia closed source drivers, there is 
a good chance that dist-upgrade will kill your X server and send SIGHUP 
to apt and dpkg, leaving you in "you need to run 'dpkg --configure 
--all'" state.


If that happens, you get another resolver run on a partially upgraded 
system.


   Simon


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: /usr-move: Do we support upgrades without apt?

[Matthew Vernon]

Hi,

On 21/12/2023 09:41, Helmut Grohne wrote:


Is it ok to call upgrade scenarios failures that cannot be reproduced
using apt unsupported until we no longer deal with aliasing?


I incline towards "no"; if an upgrade has failed part-way (as does 
happen), people may then reasonably use dpkg directly to try and 
un-wedge the upgrade (e.g. to try and configure some part-installed 
packages, or try installing some already-downloaded packages).


It may be that the mitigations necessary are worse than the risk, but I 
think the behaviour as described in #1058937 is definitely buggy.


Regards,

Matthew

Re: /usr-move: Do we support upgrades without apt?

[Marc Haber]

On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote:
> On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > using apt unsupported until we no longer deal with aliasing?
> 
> I think so, yes. I don't think it's likely that there are people doing
> upgrades on running systems not using apt.

Do those GUI frontends that work via packagekit or other frameworks
count as "using apt"? I now that WE recommend using apt in a text
console outside of X, but even many of our own users do what their
Desktop Environment does, and our downstreams like *b*nt* recommend
other ways to upgrade as well.

Greetings
Marc

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

Re: /usr-move: Do we support upgrades without apt?

[Antonio Terceiro]

On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> ## Upgrading using dpkg directly?
> 
> We already have quite a number of packages that use Conflicts to prevent
> file loss in upgrades in a very similar way to #1058937 (Ben's
> libnfsidmap1 bug) even in released versions of Debian. For instance,
> dhcpcd-base's Replaces were upgraded to Conflicts, see #1053657. If you
> employ dpkg, you can still experience the problem there.
> 
> Is it ok to call upgrade scenarios failures that cannot be reproduced
> using apt unsupported until we no longer deal with aliasing?

I think so, yes. I don't think it's likely that there are people doing
upgrades on running systems not using apt.

If there are, they already need to deal with doing the dpkg calls in the
right order anyway -- basically doing the apt dependency resolution by
hand -- that this is just another corner case that they need to handle;
there could be already Conflicts in there for other reasons than
/usr-merge.


signature.asc
Description: PGP signature

Re: Reaction to potential PGP schism

[Stephan Verbücheln]

Interesting point in this talk: The APT team is already working on non-
PGP signatures.

https://wiki.debian.org/Teams/Apt/Spec/AptSign

I can see the advantages of that for release signatures which use a
rarely changing set of keys.
However, I do not see any good alternative for PGP for personal
signatures such as developer communication and maintainer uploads. PGP
is really handy because once trust of the key fingerprint for a person
is established, the person can easily make changes such as adding
subkeys, editing the expiration date, revoking keys, etc. at any time.

This would also be less convenient with a CMS-PKI-CA-hierarchy based
system.

Regards
Stephan


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

Re: /usr-move: Do we support upgrades without apt?

[Christoph Berg]

Re: Helmut Grohne
> Is it ok to call upgrade scenarios failures that cannot be reproduced
> using apt unsupported until we no longer deal with aliasing?
> 
> If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug)
> with no action calling the scenario unsupported.

I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.

Christoph

Re: Reaction to potential PGP schism

[Enrico Zini]

On Wed, Dec 20, 2023 at 10:16:28PM -0500, Daniel Kahn Gillmor wrote:

> # Why is GnuPG on Debian's Critical Path?
> 
> In 2023, I believe GnuPG is baked into our infrastructure largely due to
> that project's idiosyncratic interface.  It is challenging even for a
> sophisticated engineer to figure out how to get GnuPG to (probably,
> hopefully!) fulfill a cryptographic task in their project.  Once that is
> done, it's especially painful to consider moving to a different OpenPGP
> implementation, because the interface to another implementation rarely
> lines up cleanly with GnuPG's interface.

I maintain critical code that calls out to gnupg, in part because at the
time I wrote it that was the only thing available, and in part because
I'm supposed to offer the broadest possible compatibility with what
other people in Debian are using, so if everyone else seems to use
gnupg, gnupg is the first thing I would consider.

I hated and still hate every single moment I spent having to interface
with gnupg. The protocol to interact with it is custom, hydiosincratic,
poorly documented, and very hard to speak correctly. When in the end I
managed to make things work, I was always left with the feeling that
there would still be a corner case that I missed, or that will be
introduced in a future gnupg release, waiting to become a security issue
in our infrastructure, despite having asked for peer review from
appropriate people in Debian.

New releases make things harder rather than easier. Now gnupg is a
mini-ecosystem of security-critical daemons that need to be brought up
and killed, that may time out or run partly off sync with configuration,
which adds even more know-how to the amount require to survive as
downstream consumer of that one single "API".

I've been wanting for literally decades something with language
bindings, or with a protocol that is built on existing well-known
standards, outputting data that I can parse with an existing and tested
parser library, using I/O channels that I can manage using an existing
and tested communication library.

I hate it every single time I need to use gnupg, but still I use it
because I understand it's what Debian has been expecting me to use, so I
add that requirement to the pile of historical quirks that geologically
accrete in our community, which make our barrier of entry so stylishly
high, and make us appear oh so fearfully smart.


> # What Can Debian Do About This?
> 
> If you are implementing or maintaining an OpenPGP implementation in
> debian, please consider encouraging upsteam to add a sop frontend, and
> get it tested in the interop test suite!

This. 

I don't know if it should be sop or a protocol or a standard, but I'd
like to see Debian clearly document its expectations on its crypto
requirements, and stand behind it.

I personally believe that we should depend, for our core security, on an
interoperable standard with multiple implementations rather than a
project that follows the hydiosincracies of a single isolated upstream.

Whatever we do, though, I want that to be official. As things stand I'll
keep suffering with gnupg until at a DebConf I'll have at least 5 people
look at me wide-eyed and say "are you still using THAT? Everyone moved
to THIS instead!"

I'd like to ask for what mature OpenPGP implementations exist today,
pick one I feel I can confidently control, and then when somebody comes
and says "my gpg/$TOOL segfaults on your input", I want to be able to
point them at a documented decision and say "please report a bug to
$TOOL" instead of taking a week off to port everything again to gpg.

Thank you for all the work you've done on this over the years! I've
appreciated it with great gratitude and a big hope that some day, thanks
to you and others like you, those >=5 people at a DebConf will really
look at me wide-eyed and show me a way out of the pit.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Reaction to potential PGP schism

[Gioele Barabucci]

On 21/12/23 04:16, Daniel Kahn Gillmor wrote:

# What Can Debian Do About This?

I've attempted to chart one possible path out of part of this situation
by proposing a minimized, simplified interface to some common baseline
OpenPGP semantics -- in particular, the "Stateless OpenPGP" interface,
or "sop", as documented here:

https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/


Hi, thanks for the detailed overview.

As the Uploader of rust-sequoia-openpgp, what do you think of the 
related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg 
that uses sequoia internally)?


Would it work as a stop-gap measure while the Debian infrastructure 
moves from GnuPG to something else (to `sop`, for instance)?


Regards,

[1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in 
Debian AFAIK


--
Gioele Barabucci

Bug#1058937: Info received (/usr-move: Do we support upgrades without apt?)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian kernel team 

If you wish to submit further information on this problem, please
send it to 1058...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1058937: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058937
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

/usr-move: Do we support upgrades without apt?

[Helmut Grohne]

Hi,

this installment serves a dual purpose. Let me first give an update of
the status quo and then pose a consensus question on how we want to deal
with a particular problem.

I Cc d-release@l.d.o as upgrades are an integral part of releases.
I Cc d-ctte@l.d.o for advisory feedback with experience due to earlier
decisions on merged-/usr.

# Status

As I detailed earlier, diversions have been proving more difficult than
anticipated. I spent significant time on molly-guard to get to a working
mitigation and thanks to Francois and Daniel, all of the diverters of
/sbin/halt and others have been updated in experimental for wider
testing. This is looking promising and passing all testing that has been
performed thus far.

Meanwhile Chris Hofstaedler and kind folks in Cambridge worked a lot on
M-A:same shared file loss (DEP17 P7) and got us down to one
(reintroduced) issue.  Pending further reintroductions, this aspect is
done. Cool! I've since uploaded debhelper and dh_installudev will now
also install to /usr. udevdir in udev.pc has been changed in a NEW
upload to experimental as well and is expected to hit unstable before
too long (thanks Michael and Luca).

Earlier, I requested a pause of /usr merges. Since we have a better
understanding and solutions that seem to be working now, I am happy for
you to move stuff again more widely. For moves involving diversions in
any way, consider having me review your change ahead of upload.

At the time of this writing, there are 1237 source packages in unstable
that still ship something aliased. This is the number we need to get
down to 0 for trixie. Of these 860 involve a systemd unit and of these
761 only have systemd units aliased many of which can be converted by a
no-change upload due to changed debhelper and systemd.pc behaviour.

# The problem with conflicts

The idea in DEP17 was to use Conflicts as a mitigation strategy in
agreement with a naive reading of Debian policy. As it turns out, that
doesn't exactly match reality (#1057199 debian-policy) and there are
situations where files can be lost despite Conflicts having been
declared. In theory, this subtlety should be irrelevant and
unobservable, but aliasing (which breaks dpkg's assumptions) makes this
observable.

We move a file from / to /usr in $PKGA.

AND one of

The file is also being moved to a different package (causing DEP17 P1).

OR

The file is being diverted (causing DEP17 P3).

AND

The mitigation involves declaring a Conflict for unpack ordering (i.e.
M7 for P1 or M18 for P3).

AND one of

The upgrade is being performed using a direct dpkg invocation
without apt in a way that unpacks the package declaring the conflict
before the conflicted package is removed. Example: #1058937 (Ben's
libnfsidmap1 bug)

OR

The involved packages declare a mutual conflict (or mutual conflicts
+ breaks) and therefore apt invokes dpkg as in the earlier point.
Example: An earlier version of the molly-guard mitigation declared
versioned Breaks for systemd-sysv.

This condition is complex, so let me try to break it down into something
simpler. We'll have somewhere between 20 and 100 instances of P1 + P3 I
guess and we aimed for mitigating most of them using Conflicts (i.e.
first two conditions). The horny part is the last one. It basically says
that as long as we only ever use apt and avoid mutual conflicts, the
issue is not practically observable.

That mutual conflict condition is delicate on its own. There are
basically two ways to trigger it. The way my molly-guard patch did it
was having two versioned Conflicts or Breaks declarations. I checked the
archive and there is no instance of any package combination doing this.
Hypothetically, another way to trigger this is unversioned Conflicts
combined with a package that drops Provides in a later version (thanks
David), but we haven't seen any practical instance and I haven't figured
a good way to gauge this problem yet.

## Options (combinations possible)

When mitigating P1, we can opt for protective diversions (M8) instead of
Conflicts (M7), though that is more fragile.

When mitigating P3, we can avoid the mutual conflicts. For molly-guard
that has been more involved, but it seems manageable. For other
packages (that do not need to access diverted files), it becomes
simpler.

We can restore lost files in a postinst. For this to work, we must
duplicate (e.g. hard link) affected files in the data.tar.
Example: #1057220 (systemd-sysv upgrade file loss)
Note that this approach is not policy compliant for essential packages
as they must work when unpacked and this is relevant for gzip being
diverted by zutils for instance.

We can introduce "barrier" packages (one or more) and have them enforce
conflicting packages removed before the conflictor being unpacked
(thanks Julian).

We can - and this is the crux of the matter - argue that upgrading with
bare dpkg is unsupported and you get to keep the pieces if you do so
anyway.

##

Re: Reaction to potential PGP schism

[Meso Security]

   Thank you very much  for your explanation   On Thu, Dec 21, 2023 at 2:13 AM, Christoph Biedl  wrote:  Daniel Kahn Gillmor wrote...(...)Thanks for your exhaustive description. I'd just like to point out onepoint:> In practice, i think it makes the most sense to engage with> well-documented, community-reviewed, interoperably-tested standards, and> the implementations that try to follow them.  From my vantage point,> that looks like the OpenPGP projects that have continued to actively> engage in the IETF process, and have put in work to improve their> interoperability on the most sophisticated suite of OpenPGP tests that> we have (https://tests.sequoia-pgp.org/, maintained by the Sequoia> project for the community's benefit).  Projects that work in that way> are also likely to benefit from smoother upgrades to upcoming work in> the IETF like post-quantum cryptographic schemes:>> https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/There was a presentation at the recent MiniDebconf in Cambridge aboutpost-quantum cryptography, including the consequences for Debian (thatwas by Andy Simpkins):https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/SimpkinsThe key point AIUI is Debian must take precautions *very* *soon* asthere's a realistic chance QC will - within the lifetime of trixie -evolve to a point where it seriously weakens the cryptographic securityas we know it. In other words, Debian must prepare for PQC within thetrixie development cycle, so within 2024.Therefore, my answer to "How can Debian deal with this [schism]?" isbasically: Debian needs to change things in that area anyway, let'sfirst find an implementation that provides what we need and has a saneimplementation. If that means turning away from GnuPG, so be it. Thetransition will be painful anyway.Christoph




publicKey - MesoSecurity@protonmail.ch - 0xA98C9ECA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Reaction to potential PGP schism

[Christoph Biedl]

Daniel Kahn Gillmor wrote...

(...)

Thanks for your exhaustive description. I'd just like to point out one
point:

> In practice, i think it makes the most sense to engage with
> well-documented, community-reviewed, interoperably-tested standards, and
> the implementations that try to follow them.  From my vantage point,
> that looks like the OpenPGP projects that have continued to actively
> engage in the IETF process, and have put in work to improve their
> interoperability on the most sophisticated suite of OpenPGP tests that
> we have (https://tests.sequoia-pgp.org/, maintained by the Sequoia
> project for the community's benefit).  Projects that work in that way
> are also likely to benefit from smoother upgrades to upcoming work in
> the IETF like post-quantum cryptographic schemes:
>
> https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/

There was a presentation at the recent MiniDebconf in Cambridge about
post-quantum cryptography, including the consequences for Debian (that
was by Andy Simpkins):

https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Simpkins

The key point AIUI is Debian must take precautions *very* *soon* as
there's a realistic chance QC will - within the lifetime of trixie -
evolve to a point where it seriously weakens the cryptographic security
as we know it. In other words, Debian must prepare for PQC within the
trixie development cycle, so within 2024.

Therefore, my answer to "How can Debian deal with this [schism]?" is
basically: Debian needs to change things in that area anyway, let's
first find an implementation that provides what we need and has a sane
implementation. If that means turning away from GnuPG, so be it. The
transition will be painful anyway.

Christoph


signature.asc
Description: PGP signature