1) The Depends will install gpgv-from-sq on new systems. The
gpgv-from-sq package diverts /usr/bin/gpgv to gpgv-g10code
and Provides gpgv, installing a symlink to gpgv-sq.
Unrelated to the apt proposal, how come dpkg-divert is being used here
by gpgv-from-sq instead of using the what-is-python/python-is-pythonX approach of just shipping a symlink?
The python-is-pythonX approach is much simpler, fully declarative (as
in: the future state of the system is statically described by the
content of the package, not at runtime), and removes the need for the maintscripts to know about the other implementations.
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
I've just finished more or less, adjusting the APT test suiteOK, but why?
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
Because there is no coordination between gpgv and gpgv-sq packages,
and
dependent packages should have no reason to care. gpgv-sq unilaterally
claims compatibility, and if something breaks as a result, that is a bug in gpgv-sq, because the interface of gpgv is defined by the g10code implementation.
I'm not happy with the heavyness that one gets via gpg just for
verifying signatures, so I'd be all for a lighter-weight solution.
An optimal mechanism would instea[...]
On 2024-11-21 Julian Andres Klode <jak@debian.org> wrote:
[...]
An optimal mechanism would instea[...]
Something seems to be missing here.
cu Andreas
On 11/21/24 15:19, Iustin Pop wrote:
I'm not happy with the heavyness that one gets via gpg just for
verifying signatures, so I'd be all for a lighter-weight solution.
gpgv is lighter weight than gpgv-sq. Surprisingly, it's not just
the rustc-static-links-everything problem, since gpgv-static is
also smaller than gpgv-sq.
On Nov 21, Julian Andres Klode <jak@debian.org> wrote:
I've just finished more or less, adjusting the APT test suiteOK, but why?
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
Did you make an analysis of how much the size of a minimal system would change?
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpgv-sq. Previous
discussions with the security team did not reveal any
blockers for that, despite the strenuous nature of
security updates for Rust packages.
As for ports without gpgv-sq, this does not affect them,
they can be served by the gpgv alternative. Once a gpgv-sq
is available, it's important to note that no migration happens
On 2024-11-21, Julian Andres Klode <jak@debian.org> wrote:
As for ports without gpgv-sq, this does not affect them,
they can be served by the gpgv alternative. Once a gpgv-sq
is available, it's important to note that no migration happens
To me it looks like we will sligthly grow the base system and have
different kind of bugs per architecture depending on availability of
rust.
On Fri, Nov 22, 2024 at 04:14:59PM +0000, Sune Vuorela wrote:
On 2024-11-21, Julian Andres Klode <jak@debian.org> wrote:
As for ports without gpgv-sq, this does not affect them,
they can be served by the gpgv alternative. Once a gpgv-sq
is available, it's important to note that no migration happens
To me it looks like we will sligthly grow the base system and have different kind of bugs per architecture depending on availability of
rust.
All release architectures support Rust. We should not accept
release architectures without Rust support.
A minor set of ports architectures does not have Rust support
yet.
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
That's correct due to some overlinking in the Rust toolchain,Do you have reasons to believe that this is going to happen in time for
there needs to be some more crate splitting to make it smaller.
1. The GnuPG upstream forked the OpenPGP standard into his own
thing called LibrePGP, and GnuPG 2.4 implements that new thing
and is by default incompatible with other OpenPGP implementations.
On Thu, Nov 21, 2024 at 11:52:38PM +0100, Marco d'Itri wrote:
On Nov 21, Julian Andres Klode <jak@debian.org> wrote:
I've just finished more or less, adjusting the APT test suiteOK, but why?
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
Did you make an analysis of how much the size of a minimal system would change?
We currently see a size increase of 8% (9MB uncompressed, 4MB gzipped) in an essential + apt bootstrap:
$ mmdebstrap --variant=essential --include=apt unstable unstable.tar
$ mmdebstrap --variant=essential --include=gpgv-from-sq,apt,gpgv- unstable unstable-with-sq.tar
$ $ ls -lh unstable*.tar
-rw-r--r-- 1 jak jak 114M Nov 22 13:39 unstable.tar
-rw-r--r-- 1 jak jak 123M Nov 22 13:39 unstable-with-sq.tar
$ gzip unstable*.tar
$ ls -lh unstable*.tar*
-rw-r--r-- 1 jak jak 46M Nov 22 13:39 unstable.tar.gz
-rw-r--r-- 1 jak jak 50M Nov 22 13:39 unstable-with-sq.tar.gz
$ diff <(tar xOf unstable.tar.gz ./var/lib/dpkg/status | grep ^Package\\\|Installed-Size) <(tar xOf unstable-with-sq.tar.gz ./var/lib/dpkg/status | grep ^Package\\\|Installed-Size) -U0
diff --git dev/fd/63 dev/fd/62
--- dev/fd/63
+++ dev/fd/62
@@ -29,2 +29,4 @@ Installed-Size: 109
-Package: gpgv
-Installed-Size: 509
+Package: gpgv-from-sq
+Installed-Size: 14
+Package: gpgv-sq
+Installed-Size: 8167
@@ -110,0 +113,2 @@ Installed-Size: 368
+Package: libsqlite3-0
+Installed-Size: 1833
There are a bunch of toolchain/crate-splitting issues here: Rust
overlinks, neither do we use all 8MB of the code that's linked
into gpgv-sq, nor does it actually need libsqlite3-0. This happens
because gpgv-sq uses gpg-sq crate, if they were split up, things
should go down quite a bit is my understanding.
All release architectures support Rust. We should not accept
release architectures without Rust support.
A minor set of ports architectures does not have Rust support
yet.
Rust is unsupported on i386 and patched to silently assume i686
- see
DEP-3 references in this patch for discussions about that, and the patch itself for a way to more loudly make reverse dependencies aware that
code using SSE2 *must* be compiled without optimizations on i386: https://salsa.debian.org/debian/rust-wide/-/blob/debian/latest/debian/patches/2001_fail_non-sse2-x86.patch
Beware that Rust team build routines run tests without optimizations, regardless of DEB_BUILD_OPTIONS=noopt, so for libraries maintained by
them the issue may go unnoticed until reverse dependencies run into the
issue *and* test for it, otherwise it might go unnoticed until users
report it.
If you want to learn more about Sequoia and the Chameleon
in particular, watch Holger's talk at this year's DebConf: https://debconf24.debconf.org/talks/16-chameleon-the-easy-way-to-try-out-sequoia-openpgp-written-in-rust/
* Jonas Smedegaard <jonas@jones.dk> [241122 18:01]:
All release architectures support Rust. We should not accept
release architectures without Rust support.
A minor set of ports architectures does not have Rust support
yet.
Rust is unsupported on i386 and patched to silently assume i686
i686 is not a problem, as that's the arch baseline for our i386
arch since bookworm.
- see
DEP-3 references in this patch for discussions about that, and the patch itself for a way to more loudly make reverse dependencies aware that
code using SSE2 *must* be compiled without optimizations on i386: https://salsa.debian.org/debian/rust-wide/-/blob/debian/latest/debian/patches/2001_fail_non-sse2-x86.patch
Beware that Rust team build routines run tests without optimizations, regardless of DEB_BUILD_OPTIONS=noopt, so for libraries maintained by
them the issue may go unnoticed until reverse dependencies run into the issue *and* test for it, otherwise it might go unnoticed until users
report it.
So maybe it's time to raise the baseline to i686+sse2.
On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grnbichler wrote:
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
As suggested by Chris, and a popular opinion/request in general.
--
WBR, wRAR
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
As suggested by Chris, and a popular opinion/request in general.
Considering that for Trixie we won't have an i386 installer, particularly:
it seems evident to me that as more software depends on Rust, less of it
will be usable on i386 (and possibly something like armhf in due course.) This whether or not we rebase the hardware requirements for an architecture.
On Sat, Nov 23, 2024 at 11:29:04PM +0500, Andrey Rakhmatullin wrote:
On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
As suggested by Chris, and a popular opinion/request in general.
--
WBR, wRAR
Considering that for Trixie we won't have an i386 installer, particularly:
it seems evident to me that as more software depends on Rust, less of it
will be usable on i386 (and possibly something like armhf in due course.) This whether or not we rebase the hardware requirements for an architecture.
On Sat, Nov 23, 2024 at 07:05:39PM +0000, Andrew M.A. Cater wrote:
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
As suggested by Chris, and a popular opinion/request in general.
Considering that for Trixie we won't have an i386 installer, particularly: it seems evident to me that as more software depends on Rust, less of it will be usable on i386 (and possibly something like armhf in due course.) This whether or not we rebase the hardware requirements for an architecture.
Sorry, I don't get it.
--
WBR, wRAR
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
As suggested by Chris, and a popular opinion/request in general.
Considering that for Trixie we won't have an i386 installer, particularly:
it seems evident to me that as more software depends on Rust, less of it will be usable on i386 (and possibly something like armhf in due course.) This whether or not we rebase the hardware requirements for an architecture.
Sorry, I don't get it.
Hi - sorry I might have conflated more than one thing
1. Rust itself is fast-moving and difficult to package/deal with. There's a couple of threads on LWN.net on this at the moment. There's a further distinction between Rust in general and Rust in the Linux kernel itself - which is further behind Rust head development. In general: Support in
Debian is difficult for fast-moving software without guaranteed backward compatibility long term.
2. Upstream Rust doesn't particularly care about 32 bit i386 - so it's a Debian thing to try and produce appropriate binaries including Rust wherever they are.
3. There are packages including Rust that can't be built on 32 bit / can't be built on some of Debian's ports. Firefox is one, I think - and there's the general problem that some larger packages like libreoffice are marginal on some architectures, without considering Rust. That situation can only get worse with time.
4. The consensus seems to be that i386 in Trixie won't have an installer built for it - there's no kernel support in the most recent kernels. The architecture is being maintained primarily for compatibility with older software (also the reason for no time_t64 transition on i386).
5. If we're moving hardware baselines for the sake of Rust (or any other software on this architecture) it's already too late.
5. If we're moving hardware baselines for the sake of Rust (or any other software on this architecture) it's already too late.
5. If we're moving hardware baselines for the sake of Rust (or any other software on this architecture) it's already too late.
Huh? Why?
[Putting my Release Team hat off] Personally I think Debian should be
raising the baseline for i386. I'm not sure about to which level, but I've seen proposals in this thread.
Given that
1) we're no longer supporting i386 as a full architecture (no kernel, no installer, only in chroots or as multiarch)
2) we don't clearly have i386 porters
maybe we should seek consensus in this thread and go with that.
[Release Team hat on] I would take consensus for a decision on the topic.
Quoting Julian Andres Klode (2024-11-22 17:36:17)[...]
On Fri, Nov 22, 2024 at 04:14:59PM +0000, Sune Vuorela wrote:
On 2024-11-21, Julian Andres Klode <jak@debian.org> wrote:
As for ports without gpgv-sq, this does not affect them,
they can be served by the gpgv alternative. Once a gpgv-sq
is available, it's important to note that no migration happens
To me it looks like we will sligthly grow the base system and have different kind of bugs per architecture depending on availability of rust.
All release architectures support Rust. We should not accept
release architectures without Rust support.
A minor set of ports architectures does not have Rust support
yet.
Rust is unsupported on i386 and patched to silently assume i686 - see
DEP-3 references in this patch for discussions about that, and the patch itself for a way to more loudly make reverse dependencies aware that
code using SSE2 *must* be compiled without optimizations on i386: https://salsa.debian.org/debian/rust-wide/-/blob/debian/latest/debian/patches/2001_fail_non-sse2-x86.patch
Hi,
On 11/24/24 17:22, Andrew M.A. Cater wrote:
5. If we're moving hardware baselines for the sake of Rust (or any other software on this architecture) it's already too late.
Huh? Why?
[Putting my Release Team hat off] Personally I think Debian should be
raising the baseline for i386. I'm not sure about to which level, but I've seen proposals in this thread.
Given that
1) we're no longer supporting i386 as a full architecture (no kernel, no installer, only in chroots or as multiarch)
2) we don't clearly have i386 porters
maybe we should seek consensus in this thread and go with that.
[Release Team hat on] I would take consensus for a decision on the topic.
[Putting my Release Team hat off] Personally I think Debian should be
raising the baseline for i386. I'm not sure about to which level, but I've seen proposals in this thread.
[Release Team hat on] I would take consensus for a decision on the topic.
[Release Team hat on] I would take consensus for a decision on the topic.
1. The GnuPG upstream forked the OpenPGP standard into his own
thing called LibrePGP, and GnuPG 2.4 implements that new thing
and is by default incompatible with other OpenPGP implementations.
Which kind of default incompatibility is implemented in GnuPG 2.4?
On 2024-11-22, Frank Guthausen <fg.debian@shimps.de> wrote:
Which kind of default incompatibility is implemented in GnuPG 2.4?
[...]
LWN did an article in december about it.
[Release Team hat on] I would take consensus for a decision on the topic.
Hi,
On 11/24/24 17:22, Andrew M.A. Cater wrote:
5. If we're moving hardware baselines for the sake of Rust (or any other
software on this architecture) it's already too late.
Huh? Why?
[Putting my Release Team hat off] Personally I think Debian should be raising the baseline for i386. I'm not sure about to which level, but I've seen proposals in this thread.
Given that
1) we're no longer supporting i386 as a full architecture (no kernel, no installer, only in chroots or as multiarch)
2) we don't clearly have i386 porters
maybe we should seek consensus in this thread and go with that.
[Release Team hat on] I would take consensus for a decision on the topic.
We currently see a size increase of 8% (9MB uncompressed, 4MB gzipped) in an essential + apt bootstrap:
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpgv-sq. Previous
discussions with the security team did not reveal any
blockers for that, despite the strenuous nature of
security updates for Rust packages.
My plan here is to use
Depends: gpgv-from-sq | gpgv-sq | gpgv
Recommends: gpgv-sq
On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpgv-sq. Previous
discussions with the security team did not reveal any
blockers for that, despite the strenuous nature of
security updates for Rust packages.
This has been delayed. There's ongoing investigation into
sqv and sqopv, which are smaller verifiers from Sequoia,
measuring only 2MB and without an SQLite dependency, hence
saving about 6MB.
On Wed, Dec 18, 2024 at 12:02:18AM +0100, Julian Andres Klode wrote:
On Tue, Dec 03, 2024 at 04:34:52PM +0100, Julian Andres Klode wrote:
On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpgv-sq. Previous
discussions with the security team did not reveal any
blockers for that, despite the strenuous nature of
security updates for Rust packages.
This has been delayed. There's ongoing investigation into
sqv and sqopv, which are smaller verifiers from Sequoia,
measuring only 2MB and without an SQLite dependency, hence
saving about 6MB.
An sqv backend is now available in apt-team/apt!409 and in
experimental in apt 2.9.17+exp1.
Note that the experimental upload only supports architectures
with sqv available. There is no fallback yet.
The plan is to detect if sqv is available at build time, by
build-depending on sqv for the correct set of architectures,
and then generate a `Depends: sqv` for those architectures,
and `Depends: gpgv` for other (ports) architectures.
The sqv binary is about 2MB large when optimized for size,
and provides good feedback when a key cannot be verified.
The Sequoia sqv backend is now the default backend in unstable
for architectures that have it (all release architectures, most
ports).
2.9.19 also replaces internal GnuTLS and gcrypt use with OpenSSL,
and all use of GnuPG in the test suite with Sequoia's `sq` command.
There is a backwards-incompatible change: Signed-By can no
longer contain an exact subkey match (suffix "!"). That
information is - rightly so - not available in the sqv
output.
On Tue, Dec 03, 2024 at 04:34:52PM +0100, Julian Andres Klode wrote:
On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpgv-sq. Previous
discussions with the security team did not reveal any
blockers for that, despite the strenuous nature of
security updates for Rust packages.
This has been delayed. There's ongoing investigation into
sqv and sqopv, which are smaller verifiers from Sequoia,
measuring only 2MB and without an SQLite dependency, hence
saving about 6MB.
An sqv backend is now available in apt-team/apt!409 and in
experimental in apt 2.9.17+exp1.
Note that the experimental upload only supports architectures
with sqv available. There is no fallback yet.
The plan is to detect if sqv is available at build time, by
build-depending on sqv for the correct set of architectures,
and then generate a `Depends: sqv` for those architectures,
and `Depends: gpgv` for other (ports) architectures.
The sqv binary is about 2MB large when optimized for size,
and provides good feedback when a key cannot be verified.
i.e. we see a 9MB saving for essential+apt, and a 4MB saving
for a default mmdebstrap.
Something still pulls in gpgv there
which is unfortunate, we lack a 5MB savings.
More savings can be achieved by building sqv using openssl,
then we stop pulling in nettle.
Something still pulls in gpgv there
which is unfortunate, we lack a 5MB savings.
* Julian Andres Klode <jak@debian.org> [241223 12:49]:
Something still pulls in gpgv there
which is unfortunate, we lack a 5MB savings.
dpkg-dev Depends: gpgv | sq | ...
That seems odd. Maybe it wants gpgv | sqv | ...
instead?
Hi!
On Mon, 2024-12-23 at 13:20:39 +0100, Chris Hofstaedtler wrote:
* Julian Andres Klode <jak@debian.org> [241223 12:49]:
Something still pulls in gpgv there
which is unfortunate, we lack a 5MB savings.
I think that would be gpgv being Priority: important, which makes
debootstrap and friends pull it in by default. I guess that might
need to be swapped now.
dpkg-dev Depends: gpgv | sq | ...
That seems odd. Maybe it wants gpgv | sqv | ...
instead?
I do have a branch to add support for sqv, should get in with the next
dpkg upload. And probably can now swap the order of preference there
too.
Hi,
On 11/24/24 17:22, Andrew M.A. Cater wrote:
5. If we're moving hardware baselines for the sake of Rust (or any other
software on this architecture) it's already too late.
Huh? Why?
[Putting my Release Team hat off] Personally I think Debian should be
raising the baseline for i386. I'm not sure about to which level, but
I've seen proposals in this thread.
Given that
1) we're no longer supporting i386 as a full architecture (no kernel, no installer, only in chroots or as multiarch)
2) we don't clearly have i386 porters
maybe we should seek consensus in this thread and go with that.
[Release Team hat on] I would take consensus for a decision on the topic.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:48:20 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,500 |