Re: merged /usr

[Marco d'Itri]

Implementations with real /bin /sbin /lib* directories and symlink farms
are not useful because they would negate the major benefits of 
merged-/usr, i.e. the ability of sharing and independently updating 
/usr.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Accepted cpio 2.13+dfsg-6 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 13 Aug 2021 13:06:27 +1000
Source: cpio
Architecture: source
Version: 2.13+dfsg-6
Distribution: unstable
Urgency: high
Maintainer: Anibal Monsalve Salazar 
Changed-By: Anibal Monsalve Salazar 
Closes: 992098
Changes:
 cpio (2.13+dfsg-6) unstable; urgency=high
 .
   * Fix regression of original fix for CVE-2021-38185
 Add patch 992098-regression-of-orig-fix-for-CVE-2021-38185
 Closes: #992098
Checksums-Sha1:
 f7a94584c9b5e4a4c78988f3ba20ea2af5118217 2000 cpio_2.13+dfsg-6.dsc
 9ee01a1b21b5519aa1404b17cf6d541c2fc614be 35932 cpio_2.13+dfsg-6.debian.tar.xz
 4dc7afbf494b9023676863623a99b9561986d0c7 5623 cpio_2.13+dfsg-6_amd64.buildinfo
Checksums-Sha256:
 e2f34bf312a70a4a5bcfe28e32698460566ddbde1c66e3293e44268a1f01c202 2000 
cpio_2.13+dfsg-6.dsc
 f375c98097f52cedc6f7ef6257201540a6f30302548068d786970272b774430a 35932 
cpio_2.13+dfsg-6.debian.tar.xz
 31d3a2f4cc8cab6f6f4df6102f52ed6a7278027c2c3dc490380ce978f5c13f72 5623 
cpio_2.13+dfsg-6_amd64.buildinfo
Files:
 c0c3992cb60e6b12e88ea40990f89509 2000 utils important cpio_2.13+dfsg-6.dsc
 e5d49ce6b89e4a822cd4e62dac9850e1 35932 utils important 
cpio_2.13+dfsg-6.debian.tar.xz
 0f3b6bff97cd40736fe7c0b0f635e0e6 5623 utils important 
cpio_2.13+dfsg-6_amd64.buildinfo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJhFeUfAAoJEHxWrP6UeJfYw7QQALiZPUhmER3QXfcEbre0xsya
BGqYady59xtDxvOCoVFS2zOP/nsnmR7bBwDA6E+xk8bw/+OkkVps/QgROE6I+AM2
TzVIa6BjgpDITs21k6XYPSUQS+8iz8mfX3kY9R4WMg2FQ+pYMoLosn1Y/BBnJ47g
N3TEoLfa9Maye0n4TR2EW0VzxgMWX5/s9CJc1jksLO+jdX0yHHxdPEL2iX7hnGUJ
fUfNBwc5QIG8KySVe/0cMTPZdXtdr125GxFotb3GA7eWhk07iaFb1VT02WOolJGd
pGhNp/RTmtWrlF6NQVHW5qd/bdH9pi/3QzUowKeN0AmzHH2hGVHBkimcDhMq+YKg
XdQpakKDNdP8gvbZ/i4j8hJWYOmqSN5ku+1bFAqRBsWom0sSo0NUBD/aokP2apaq
LNdRv6tM7fYXkKqHh0UucAPfqz0OBgHCspC5If6pYdIz5/HKJyIkx4uOErjBupY8
v+PgptRkaAN2Z/kSRS5nZhd/oB0aUact2ywTskKMWAFOTKFUJG/li5ERCpLEQxNj
m/H+jE3LZN0gmJnIbBRdD1lEg/B7fZvjPoCUXbAdmXvHuNC6ZC1N7abBlvdWzbCE
ZekNmbSAWg7BeYDo4jll/LoD9S0gGOj0kfkR9MMYNc1EYOe/fHdi/gAUpsTGx63h
5J4apRr9yxhGToXImb67
=T3rY
-END PGP SIGNATURE-

Work-needing packages report for Aug 13, 2021

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1225 (new: 0)
Total number of packages offered up for adoption: 204 (new: 0)
Total number of packages requested help for: 60 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 1225 packages are
orphaned.  See https://www.debian.org/devel/wnpp/orphaned
for a complete list.



No new packages have been given up for adoption, but a total of 204 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 1034 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc bfh-container-server
   courier-webadmin cvsweb debbugs-web doc-central (139 more omitted)
 Installations reported by Popcon: 90924
 Bug Report URL: https://bugs.debian.org/910917

   asciio (#968843), requested 355 days ago
 Description: dynamically create ASCII charts and graphs with GTK+2
 Installations reported by Popcon: 67
 Bug Report URL: https://bugs.debian.org/968843

   aufs (#963191), requested 418 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 11152
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 1716 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker sbuild-qemu
 Installations reported by Popcon: 1187
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3609 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 571
 Bug Report URL: https://bugs.debian.org/642906

   cargo (#860116), requested 1584 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 2284
 Bug Report URL: https://bugs.debian.org/860116

   courier (#978755), requested 224 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-ldap courier-mlm courier-mta courier-pcp courier-pop
   courier-webadmin couriergrey (3 more omitted)
 Installations reported by Popcon: 969
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 158 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common btrfsmaintenance
   buildd checksecurity clamtk cricket email-reminder exim4-base (20
   more omitted)
 Installations reported by Popcon: 195648
 Bug Report URL: https://bugs.debian.org/984736

   cyrus-imapd (#921717), requested 916 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 420
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 2150 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (78 more omitted)
 Installations reported by Popcon: 195162
 Bug Report URL: https://bugs.debian.org/799864

   dbad (#947550), requested 593 days ago
 Description: dnsmasq-based ad-blocking using pixelserv
 Bug Report URL: https://bugs.debian.org/947550

   debtags (#962579), requested 428 days ago
 Description: Debian Package Tags support tools
 Reverse Depends: packagesearch
 Installations reported by Popcon: 1469
 Bug Report URL: https://bugs.debian.org/962579

   dee (#831388), requested 1854 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0
   libdee-dev libunity-dev libunity-protocol-private0 libunity-tools
   libunity9 zeitgeist-core
 Installations reported by Popcon: 25084
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 2539 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 4056
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#800413), requested 2144 days ago
 Description: scripts to make the life of a 

Re: Arch triplet for uefi applications

[Guillem Jover]

On Tue, 2021-08-10 at 12:34:18 +, Bastien Roucariès wrote:
> I am going to compile shell.efi from source.
> 
> I whish to install to something stable, but I need an arch triplet
> in order to put in a multiarch (like) location.

Multiarch-based pathnames should only be used by multiarch-conforming
packages for matching and existing dpkg architectures, otherwise we'll
end up with a mess of conflicting paths if we ever add such real
architecture.

Where 
comes to mind.

In addition the main reason we had to add the multiarch tuples was
pretty much to workaround the problem with i386 using varying CPUs in
the GNU system name (i486, i586, i686), so using anything but i386
there would be adding insult to injury. :)

> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  
> and 
> i686-uefi-none ? Note that grub use x86_64-efi

The vendor always gets ignored in the dpkg context.

Although is there really a need for a cross-compiler here, or is
something like -ffreestanding enough?

> I suppose we should register these triplet somewhere, and I suppose it is 
> config-patc...@gnu.org ?

https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F

Thanks,
Guillem

Re: merged /usr

[Guillem Jover]

On Tue, 2021-07-27 at 13:23:46 -0400, Calum McConnell wrote:
> > Of course, having to unnecessarily add more maintainer scripts to
> > handle something that dpkg can do perfectly fine on its own
> 
> TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg,

In my mind that's "false", but whatever yes… given that the reversion does
not appear forthcoming, other new features might indeed be needed in case
people do not want to be forced into this train wreck in slow motion.
And as I mentioned on my first reply in this thread I'm prepared to
devote any necessary volunteer time to implement such things in detriment
of other Debian work if necessary.

> and since the quote above seems to indicate you'd be willing to do that,
> why not just change dpkg to support aliased dirs?

I've mentioned this multiple times now, firstly because I think it
would still be a broken layout. Secondly, because there are different
types of dpkg features, some can be used right away, some others will
still need at least two release cycles to be usable. The features that
I think might be needed to be able to avoid being forced into using
merged-usr-via-aliased-dirs, such as registering arbitrary files are of
the former category. The features that would be needed to add support
for merged-usr-via-aliased-dirs would be the latter.

> Another way forward is to transition existing systems without merged-usr
> to a merged-usr-via-symlink-farms.  To accomplish this, we need the
> ability to create symlinks in installations that are not usrmerge, but to
> not create those links in installations that are.  That requires either
> maintainer scripts or a change to dpkg.  You just criticized maintainer
> scripts, so I would assume that they are not your favorite solution. 

Having to add maintainer script usage would be non-ideal, but would be
better than being forced to use merged-usr-via-aliased-dirs.

> Furthermore, others have pointed out that essential packages need to work
> before maintainer scripts are executed.  This behavior is codified in
> policy: 

> > "Since dpkg will not prevent upgrading of other packages while an
> > essential package is in an unconfigured state, all essential packages
> > must supply all of their core functionality even when unconfigured".

That's not what policy says. "unconfigured" does not mean that
*maintainer scripts* have not been executed.

> In other words, using maintainer scripts to create the symlinks that
> enable the core functionality of these packages during configuration is a
> no-go without a revision to policy and a change to dpkg (which might be
> impossible).  That means the symlinks would need to be included in the
> package declaratively: but simply shipping them would break the existing
> merged-usr installations.  We've already established that un-merging and
> then re-merging every installation isn't going to happen: so we'll need to
> get the file references in place using a method that isn't shipping two
> aliasing files and doesn't require maintainer scripts.

This is based on an incorrect premise. In addition, as I've also said
elsewhere bootstrapping is outside the realms of debian-policy anyway.

> Simply modifying dpkg to automatically produce symlinks from /bin to
> /usr/bin at unpack time is not enough either: dpkg isn't necessarily the
> tool doing the unpacking, and so other tools would need to be modified,
> each one of them checking for a merged-usr and then accounting for it if
> needed.  This solution is actually viable: it would lead to a working
> system, and not break the essential guarantee.

This is still based on an incorrect premise. And even though I'd find
what you propose to be a major kludge, all bootstrappers I know of,
always end up running dpkg over all .debs to do a proper installation
of any possibly manually unpacked package. And not to mention that
bootstrappers that support merged-usr-via-aliased-dirs have required
implementing an explicit kludge for it.

Regards,
Guillem

Accepted gnome-tweaks 40.0-1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 13 Aug 2021 01:06:19 +0200
Source: gnome-tweaks
Built-For-Profiles: noudeb
Architecture: source
Version: 40.0-1
Distribution: experimental
Urgency: medium
Maintainer: Debian GNOME Maintainers 

Changed-By: Gunnar Hjalmarsson 
Launchpad-Bugs-Fixed: 1935569
Changes:
 gnome-tweaks (40.0-1) experimental; urgency=medium
 .
   * Team upload
   * debian/watch: Updated to follow the new GNOME versioning scheme
   * New upstream release (LP: #1935569)
   * Bump debhelper-compat to 13
   * Bump Standards-Version to 4.5.1
   * Add Rules-Requires-Root header
Checksums-Sha1:
 70badc5bd608bc23f1f166769c6d7ccb938a3063 1769 gnome-tweaks_40.0-1.dsc
 1e8a5f0e4c2cddaeb2672804945d04130fca4b86 251908 gnome-tweaks_40.0.orig.tar.xz
 6652ae008db5d3132f53d12caf419a6381b0442f 6776 gnome-tweaks_40.0-1.debian.tar.xz
 45d8055b5ac9ba6cf604159e1ce0e6c5dded3247 11590 
gnome-tweaks_40.0-1_source.buildinfo
Checksums-Sha256:
 d78cebdbd54a090d5e7788b377a66103d60606799aa4d3a8e9a4f86c79e60f28 1769 
gnome-tweaks_40.0-1.dsc
 f95f3fe031b0b01c02f79a1659f889152d3772ae3e44df8403d1460ba5eec36a 251908 
gnome-tweaks_40.0.orig.tar.xz
 e59ba1cd2cc77f936f44ca4147260789c15444e01fb793850e7de1d1b532d40b 6776 
gnome-tweaks_40.0-1.debian.tar.xz
 4f462e5482d39ed46ee13fd1ed408217298e2b41cd36731f625c606995e6af9e 11590 
gnome-tweaks_40.0-1_source.buildinfo
Files:
 69f3a3e50a24c0c208bc739a10dacb09 1769 gnome optional gnome-tweaks_40.0-1.dsc
 81b5883a6f0046f1b63cc998829d83e4 251908 gnome optional 
gnome-tweaks_40.0.orig.tar.xz
 8e4b9188a012ea83e242218ca2e11d9f 6776 gnome optional 
gnome-tweaks_40.0-1.debian.tar.xz
 607915d576de8256495684174b7c42e8 11590 gnome optional 
gnome-tweaks_40.0-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEDP6Ze3JFgKf6cvjP8LEQ51ppLzIFAmEVqo0ACgkQ8LEQ51pp
LzKGhwgAqpVXgsa+gk8cnUi547McChgZgZ7GxzGTwH44XuRlFpZtnPnpadMTICsg
ZE6A7UuZ64k641z4Paxrpbj5iwMSSwZxlp/AkyU88qr93HKQNoPv+EzWXC/AxTnw
RALlSvPS5vPUkufOrSR+9Hy9bkhGK7GzsbIpTSYICQU8cFz2D+LnBe0K9zXg4iGW
hq5l6YfTru4CQ/t5uRnXk1928UIZNmZC+JkBOQU7r/6LCWH7xDe59QIXAhW60rJa
B/qPP2AtfsJgmVFdr434W9L3sSjjQ8N+8n5lj71NokD/t9bDX1vOUleAE6Fl4Qmz
3DrcAeDNrBwE8YyQpM7OuZnhbtZtuw==
=+2jp
-END PGP SIGNATURE-

git workflows (was: Steam Deck: good news for Linux gaming, bad news for Debian :()

[Sean Whitton]

Hello Romain, others,

On Thu 12 Aug 2021 at 02:06PM +02, Romain Porte wrote:

> I think this is a major point. I am a new Debian contributor after a
> good time of ArchLinux PKGBUILD writing. I find Debian technically
> superior on the packaging side, and would not trade it for PKGBUILD. But
> there are so many ways to do things. After a lot of exploration, I have
> found that the tooling that I was the most comfortable with was:
>
>   * Salsa VCS
>   * GBP for git + patching (+ DEP-conformant branch names)
>   * dh
>
> However there are so many other ways to do things. Some packages are not
> on Salsa. Some packages use manually generated diff files. Different
> branch names everywhere (debian/latest vs. debian/master vs.
> debian/unstable vs. master…). I think progressive enforcing of a
> workflow would help new maintainers to not be lost in the packaging jungle.
>
>> I still trust Debian to be the most technically excellent distribution,
>> but that's not all it makes to stay relevant. My point is that it would
>> help to reduce the technical liberties we take in Debian. However, I
>> don't think that's who we are.
>
> Maintainers like their freedoms, but enforcing some tools at some point
> could make it easier for everyone to contribute and not relearn the
> packaging process for every package, because currently every package is
> different. We are getting there by looking at the number of "3.0
> (quilt)" packages and "dh" usage, but when a package does not conform to
> this norm, it triggers a mental freeze on my side (and I want to migrate
> it all to dh/3.0 quilt etc.).

I understand your frustration and I appreciate you persevering with
involvement in Debian -- thank you!  I'd like to offer a brief
counterpoint to some of what you say, however.

In many cases, indeed, the reasons why things like dh are not in use is
simply that no-one has taken the time to update the package yet, as you
say.  However, in other cases it is because the maintainer has thought
through the options and decided against using those particular tools and
workflows for principled reasons.

For example, there are those of us who think that the downsides of the
combination of 3.0 (quilt) and patches stored unapplied in git are
significant, and so we have made attempts to provide alternatives, such
as git-debrebase.  Contributing to Debian would be a lot less fun if we
were asked to just set these reasons aside and use something which to us
is clearly technically inferior.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Jonas Smedegaard]

Quoting Andreas Tille (2021-08-12 23:06:47)
> On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote:
> > Maintainers like their freedoms, but enforcing some tools at some 
> > point could make it easier for everyone to contribute and not 
> > relearn the packaging process for every package, because currently 
> > every package is different. We are getting there by looking at the 
> > number of "3.0 (quilt)" packages and "dh" usage, but when a package 
> > does not conform to this norm, it triggers a mental freeze on my 
> > side (and I want to migrate it all to dh/3.0 quilt etc.).
> 
> +1
> 
> May be we start defining workflow recommendations in policy or we 
> draft some development policy.  I'm aware that there are may be < 100 
> packages inside the Debian package pool that are hard to push into 
> some default shape - but most packages with "unusual" workflows are 
> that way for no good reason.

>From where do you get those estimates?

I think a good start would be to try identify which packages are 
maintained in which style and for which reasons.

I imagine that https://trends.debian.net/ can help to some extend but 
that's not enough to identify e.g. how many packages use cdbs due to 
being tied to Haskell, or how many packages of a certain "smell" have 
seen no recent maintainer update.

Just an idea for a concrete task that I think would help us understand 
what is holding back progress towards streamlining of packaging.  I am 
not volunteering to do the work myself, sorry: I have too much on my 
plate already.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Accepted systemd 249.3-3 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 12 Aug 2021 22:45:02 +0200
Source: systemd
Architecture: source
Version: 249.3-3
Distribution: experimental
Urgency: medium
Maintainer: Debian systemd Maintainers 

Changed-By: Michael Biebl 
Changes:
 systemd (249.3-3) experimental; urgency=medium
 .
   * Use C/R/P for systemd-sysusers and systemd-tmpfiles.
 It's an interface/facility that can only be provided by a single package
 at a time.
Checksums-Sha1:
 4bb133886219039441c7cbbf081ef0a2e4309a28 5417 systemd_249.3-3.dsc
 76949dc3e64ae3137b224bf4ac878fca6f607381 157556 systemd_249.3-3.debian.tar.xz
 29eeac46a706c77a1cd443a19dabf9f838ac9cea 9346 systemd_249.3-3_source.buildinfo
Checksums-Sha256:
 8f02fc716cfa3dc9b406e3a8f7b2961ab9ab1a1ee4fc6174d5e234659ad43015 5417 
systemd_249.3-3.dsc
 76f02e1b10138071838b3e7caefa3430c6627eedfc2df93710191e089cad5302 157556 
systemd_249.3-3.debian.tar.xz
 be8f6b070699161562602d86e4dafeaf5ec61a02cf8a5e550e51b810dad300c8 9346 
systemd_249.3-3_source.buildinfo
Files:
 eee10176539f4a2c9d0d89cf4854aa93 5417 admin optional systemd_249.3-3.dsc
 a020b2ea8f0feb960ef519ee033ab9d0 157556 admin optional 
systemd_249.3-3.debian.tar.xz
 747cc790f34bf2fc57c9dad4c177aeac 9346 admin optional 
systemd_249.3-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmEViLwACgkQauHfDWCP
ItybMA/8DR2UBmBt0wKLXVcpx59fYkSJDQH4mVKYVfl6nYtN9IDwNOKFO00GkiAt
ZU9Dg5Gha7UNPn2D4RJq5VY75uvxlGV1u+UpMhmw/guKskLr0kzV2lnk+O4VWG+9
+zENrG6ejWqaKhZMUEFe0E/BwF7TvwncUq6ol7woADOV62NZ9HcvmGhVdR0rBltU
hO2ha8bUeZeg1EiKAs8CSqu3BDw9waaPi5KQAotRnazY9MNTnqII2R/eluBn8gk7
mElqiR82WPSIxYCNnkiamkzq/YnKyiB4z47uGwgHVf7iRyu3755LI0O3BywoSe8u
fCw0syyhmBWIsu1xnTcqGlvuyyq6C1PYMnO4haGHCiqZJJyO4Eqtvggd9VZVGoXG
XJJcXbgjjMeqdYguO/TizLhWU2Bk9fhNjL0VJUKnTq4je+5ZsjS+GTh54F2/VZYJ
qL82nJfgg6KJRgm/jECv/LM1jBsh2k/3hWJYkjMXJwK4qYkmD5+s/aL8+e/ef3Mj
YVDbUQIV7XyFLyu8JdqkQq1pnvv5UC/4N0PrYRR/zcc1VO59TQYtgOjbMPKG3qfH
JQajm32dhsIkXJ53g5dMhaq5fCB4ZJzUL2bJeEcyZTsVL+yhki4F3QLMWC9qnw9W
U81uNUPKCzdf1kZKKMSkF7LERNix3qHIPfTa1FAhicK+xgCcYsA=
=eFKY
-END PGP SIGNATURE-

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Andreas Tille]

Hi,

On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote:
> > Looking at Arch, one workflow, one way to package, one init system, etc.
> > Looking at Fedora, one workflow, one way to package, one init system.
> 
> I think this is a major point. I am a new Debian contributor after a
> good time of ArchLinux PKGBUILD writing. I find Debian technically
> superior on the packaging side, and would not trade it for PKGBUILD. But
> there are so many ways to do things. After a lot of exploration, I have
> found that the tooling that I was the most comfortable with was:
> 
>   * Salsa VCS
>   * GBP for git + patching (+ DEP-conformant branch names)
>   * dh
> 
> However there are so many other ways to do things. Some packages are not
> on Salsa. Some packages use manually generated diff files. Different
> branch names everywhere (debian/latest vs. debian/master vs.
> debian/unstable vs. master…). I think progressive enforcing of a
> workflow would help new maintainers to not be lost in the packaging jungle.

Amen.
 
> > I still trust Debian to be the most technically excellent distribution,
> > but that's not all it makes to stay relevant. My point is that it would
> > help to reduce the technical liberties we take in Debian. However, I
> > don't think that's who we are.
> 
> Maintainers like their freedoms, but enforcing some tools at some point
> could make it easier for everyone to contribute and not relearn the
> packaging process for every package, because currently every package is
> different. We are getting there by looking at the number of "3.0
> (quilt)" packages and "dh" usage, but when a package does not conform to
> this norm, it triggers a mental freeze on my side (and I want to migrate
> it all to dh/3.0 quilt etc.).

+1

May be we start defining workflow recommendations in policy or we draft
some development policy.  I'm aware that there are may be < 100 packages
inside the Debian package pool that are hard to push into some default
shape - but most packages with "unusual" workflows are that way for no
good reason.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Accepted node-shelljs 0.8.4+~cs0.8.9-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Aug 2021 01:27:39 +0530
Source: node-shelljs
Architecture: source
Version: 0.8.4+~cs0.8.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Pirate Praveen 
Changes:
 node-shelljs (0.8.4+~cs0.8.9-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Bump debhelper from old 11 to 12.
   * Set debhelper-compat version in Build-Depends.
   * Set upstream metadata fields: Bug-Submit.
   * Remove obsolete fields Contact, Name from debian/upstream/metadata
 (already present in machine-readable debian/copyright).
   * Update standards version to 4.4.1, no changes needed.
   * Remove constraints unnecessary since stretch:
 + Build-Depends: Drop versioned constraint on node-glob and nodejs.
 + node-shelljs: Drop versioned constraint on node-glob and nodejs in
   Depends.
 .
   [ Pirate Praveen ]
   * Add @types/shelljs as component
   * Update github watch file regex and use version 4
   * New upstream version 0.8.4+~cs0.8.9
   * Add @types/shelljs as component
   * Update github watch file regex and use version 4
   * New upstream version 0.8.4+~cs0.8.9
   * Switch to dh-sequence-nodejs auto install
   * Bump Standards-Version to 4.5.1 (no changes needed)
   * Bump debhelper compatibility level to 13
Checksums-Sha1:
 939759040ab50c9ba8edf9624968752f8dd183b7 2437 node-shelljs_0.8.4+~cs0.8.9-1.dsc
 45dd8501aa9882976ca3610517dac3831c2fbbf4 8666 
node-shelljs_0.8.4+~cs0.8.9.orig-types-shelljs.tar.gz
 44e916b6d6488b6ce850aaed3a3e0dde00aaeb2c 138082 
node-shelljs_0.8.4+~cs0.8.9.orig.tar.gz
 aeb42fcecab542e88099cbc8ba805ab9c3e2a6d0 3772 
node-shelljs_0.8.4+~cs0.8.9-1.debian.tar.xz
 26dc791ed5d4852230f2f17e491b96f970e96bc1 7697 
node-shelljs_0.8.4+~cs0.8.9-1_amd64.buildinfo
Checksums-Sha256:
 b799db981ef690ca0252520847d64061e50d6a0535e2989791681408864e96ab 2437 
node-shelljs_0.8.4+~cs0.8.9-1.dsc
 25e345f3f789057555d49ca7d27e089294db48d8a00e28d290f7309b9b51211e 8666 
node-shelljs_0.8.4+~cs0.8.9.orig-types-shelljs.tar.gz
 d3b7728b0df19b471ccfd42421deda4a9a9915967eb20e5dd81856019c8c6fa5 138082 
node-shelljs_0.8.4+~cs0.8.9.orig.tar.gz
 42311588f22fb59efc7cf63f91b20df36bf26eb9f37a8ac544793cf2136315a3 3772 
node-shelljs_0.8.4+~cs0.8.9-1.debian.tar.xz
 8aee9d427b6399caea79f63b2a3fe6b989916e480d417b8dc9f655870588e5b1 7697 
node-shelljs_0.8.4+~cs0.8.9-1_amd64.buildinfo
Files:
 ce9017fc121c6a3738fec2fd0af7329f 2437 javascript optional 
node-shelljs_0.8.4+~cs0.8.9-1.dsc
 5456d603657dea918a4e90d3dd6db924 8666 javascript optional 
node-shelljs_0.8.4+~cs0.8.9.orig-types-shelljs.tar.gz
 557bc6ebb42faf4faf8003947591c399 138082 javascript optional 
node-shelljs_0.8.4+~cs0.8.9.orig.tar.gz
 3f9b1e3e8ebd6c0e3f2c65a433449b88 3772 javascript optional 
node-shelljs_0.8.4+~cs0.8.9-1.debian.tar.xz
 8e31110a34818f76b59692d38102b7c3 7697 javascript optional 
node-shelljs_0.8.4+~cs0.8.9-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE0whj4mAg5UP0cZqDj1PgGTspS3UFAmEVgIcACgkQj1PgGTsp
S3W0tQ//RGbmUCDJodyQhhXz92VBetXy+pIv5UuTF6Rnspud3nrMVZtiw35an8K9
Y2S4Fd44qADtLMdC9HEnn6orC4fHWYh/VJcvTMcOQKWIDy5ZAlarvvPU2g7Fw9Ea
Ie0Kmnq2pqgN4KXe1xHqH5845JR7ql0Ayoect8/nhCWcXksQkkDGWUh8EGPEOtKE
NUBESeRBkzpMMl1WRzNdrw9UqrHga4YhCHbBiCjo5Cr0Ml9W9m8pD7BYOpSh63Iv
AH4YsZGu9P3/4q5jqhMX7C8AqEHm0EFEDe60dYd+suuxYU2/dogZ9Q38xBbqKmEt
+VubI5VX/AqrkM7dGIvZaTjR+kLRgspBeTuyQdLwjhV39EBErixEGJ7esbx25dve
C+Z0dQ1qNntEnfu+feK6mM5tmCKrKffEGwJoOIjGhK5rYv4jebXcoIPNjJDjH0lc
YjXqmxWU2d5ordpzsi9duCfJPkKnIkw++c97S0QN4vC2amFaIVLmVryRhzMhOQtw
+sXQdH8lkzH4jJ2Npz3KF/Mvzw0MKvXQmjopW3/LLbG1Wc/gQJU3VvIZjh1fBXCz
LyKFSMb9awuGq+MqeohIRuUtF+ju3qtacJHGiCKBIZ90PWq9OOa9sx2CCSyE/gQ4
9EXyil5WvDDiVdWRErV57c5iYcFPfgLVO8akmTvtHCyfpcEdnxo=
=bM6K
-END PGP SIGNATURE-

Bug#992133: ITP: firebird4.0 -- Firebird RDBMS (version 4.0)

[Damyan Ivanov]

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

* Package name: firebird4.0
  Version : 4.0.0.2496
  Upstream Author : Firebird developers (firebird-de...@lists.sourceforge.net)
* URL : https://www.firebirdsql.org/
* License : Mostly Initial Developer Public License 1.0 (MPL-like)
  Programming Lang: C++, C
  Description : Feature-rich, scalable relational database

Firebird 4 is the next generation following firebird 3 (available as 
firebird3.0 in Debian). Compared to firebird 3, this version adds:

 * Built-in logical replication;
 * Extended length of metadata identifiers (up to 63 characters);
 * New INT128 and DECFLOAT data types, longer precision for NUMERIC/DECIMAL 
   data types;
 * Support for international time zones;
 * Configurable time-outs for connections and statements;
 * Pooling of external connections;
 * Batch operations in the API;
 * Built-in cryptographic functions;
 * New ODS (version 13) with new system and monitoring tables;
 * Maximum page size increased to 32KB.

It needs to be packaged separately because the on-disk database format is not 
compatible with firebird3.0.

The packaging is based on firebird3.0, with updated copyright and patches.

Re: Figuring how to work with team-maintained packages on salsa

[Sean Whitton]

Hello Helmut,

On Sun 06 Jun 2021 at 09:58PM +02, Helmut Grohne wrote:

> There is another issue affecting me, that may derail from the original
> topic. When I work with packages I tend to fix bugs that are reported by
> some CI system on unstable. When I dgit clone, I may get the unstable
> version or I may get unreleased changes that may work or may be broken.
> That's not what I want. Instead, I strongly prefer working with exactly
> that version that produced the failure in CI. Even accidentally using
> experimental often produces wildly differing results. Beyond that, I
> don't want my trust root for software to reside in SSL certificates. I
> haven't found a way to ask dgit to produce a git tree that exactly
> produces the source package signed by unstable reliably.

I think there is some confusion.  'dgit clone' should always get you
what is in unstable, and thus exactly what the CI system was using.  It
would be a bug if it gave you unreleased changes, and I don't think
we've ever seen a bug report like that.  (The only exception I can think
of is if mirror sync issues interact with your clone, but I think there
is code to try to avoid that.)

> Admittedly, not working with unreleased changes makes integrating them
> harder for the maintainer. That's certainly a trade-off between my time
> and their time. I've chosen that I'm unwilling to work with unreleased
> changes of arbitrary packages. Their quality is too unpredictable to me.

Yeah.  'dgit clone' is meant to be useful in exactly this situation.

>> What dgit doesn't really help you with is integrating those patches
>> directly into the maintainer's repo, if the maintainer invites you to
>> push your changes directly, which is perhaps what Florian was looking
>> for.
>
> Yes, that. debdiff kinda is the universal format here as it is
> recommended in the developers reference and can be produced for
> arbitrary packages. bugs.debian.org is a universal communication method
> to package maintainers. It's a bit annoying, but universal (inside
> Debian).
>
> Thinking more about this, there is one project of Jelmer that is getting
> closer to reintegrating changes. It is silver-platter, which really
> attempts to grok maintainers' idiosyncrasies and produce patches in the
> way they desire. As far as I know, it actually works with a significant
> portion of the archive already as it backs janitor.d.n.
>
> If everyone was using dgit, then yes it would be providing that
> homogeneity much like dh does provide homogeneity on the packaging
> helper level now. The way it currently is, dgit unfortunately is
> https://xkcd.com/927/ (standards). We really cannot have both workflow
> diversity and homogeneity. Either of them must be unhappy and dgit
> chooses not to make the workflow diversity people unhappy. The price for
> homogeneity is telling a significant number of people that they cannot
> continue using their workflow and making them very unhappy that way.

I think you might be mixing together debdiffs as the universal way to
share changes, and the problem of integrating changes into maintainer
git trees.  The former dgit is useful for -- it can help you produce
debdiffs to send to the BTS in a way that's more sane than working with
raw source packages outside of VCS.  The latter is the harder problem.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Accepted orthanc-python 3.3+ds-1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 20:55:31 +0200
Source: orthanc-python
Architecture: source
Version: 3.3+ds-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Sebastien Jodogne 
Changes:
 orthanc-python (3.3+ds-1) experimental; urgency=medium
 .
   * New upstream version
Checksums-Sha1:
 49621b5049a3bc5364d65fc9e52b983c7ed3a40f 2151 orthanc-python_3.3+ds-1.dsc
 3f27e7280efe74f4f908e652065d373b08a007b2 105760 
orthanc-python_3.3+ds.orig.tar.xz
 dc4a37b06b010ae02c9b1f9d886b192714679fdd 4260 
orthanc-python_3.3+ds-1.debian.tar.xz
 6bd514e8eae0c283b60de53a823d118fc01d0d8d 14735 
orthanc-python_3.3+ds-1_source.buildinfo
Checksums-Sha256:
 f963b70d5be2e339c0ad0721ad150a403431cbcb813e3bb9d373f44cc4ef3625 2151 
orthanc-python_3.3+ds-1.dsc
 cc4b64da99b8eb8c67138cb6742ef5e5aab4d4f15dada6061570b2ebbe77f094 105760 
orthanc-python_3.3+ds.orig.tar.xz
 629804e87c553933070b254510412a04e3ff4044c0595966bf727e40fa763a30 4260 
orthanc-python_3.3+ds-1.debian.tar.xz
 b0267e6da04a54602e093e933c5f30456723863bc2b0918e6e52b59408edaf82 14735 
orthanc-python_3.3+ds-1_source.buildinfo
Files:
 d9201306625e5b85838d62445b56e3f0 2151 science optional 
orthanc-python_3.3+ds-1.dsc
 63f7b913f422bef13abe3d09039a812f 105760 science optional 
orthanc-python_3.3+ds.orig.tar.xz
 ef88918de5816b4d596af5db21ef48a9 4260 science optional 
orthanc-python_3.3+ds-1.debian.tar.xz
 aa20b0e821e01a06f9373b2967efd4a2 14735 science optional 
orthanc-python_3.3+ds-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEk76fGX7V0MMOWT2Lp3ZYKzEqw10FAmEVcIkUHHMuam9kb2du
ZUBnbWFpbC5jb20ACgkQp3ZYKzEqw138wxAAqsfkmcgvn98liuTzuCiVnSzc8oq8
mrrS6ALKfwb2teAsR5cp2kwEl6aqu6qouXRwL06XAszpugW7W3+/GmuB0YWXVwSU
iavCbnQ4Cucqs8IkZ2HwCmLkmShUhROqiQP2VyZ4eU2XI3vUQG/AjRFNbutjZwCB
E0rXGPrdDOhDHqHgDFCtCZcatLGsz4WAoI54a4qJUOheAxRp/YzcLXsnh1dcaVLC
xCObtsheGCTsf2EgT3We05DAQohUFCqbIIxnC5ZPdz8hCAq3FKEZOLFKNc38r3mF
LUrCm8DPVH1AR6/9DX769N6/6sMO3t1mHCucgmnkYn08/43ZzUkYHUDVeSV5fe9m
EuRpWgPA/l25PFE35Jo0J/4+1I2/EtGYffFG0bxDJmdt5+3ze+WG5DUv+LPrt8DO
dUoLT4iTJeDcRMy8ynBDW4uJAx3c6sXmMCFLKgGgD1h3b48YvrRJVX+p9oK3FrGY
alUMqA+gEJtPReA2PFABf7/7k3iiQSCkQWNKLQHLTQRbW4wyDcgr6lOIYjpYzWAb
aWW80KpqoP9VVBDtAgTF1BIOcNG/l218tcGWhzGTtWl8YGpEbBAZ20nrbWri1NnK
ZqQsdy83kmqqDNiLnIt3pMMev9Nqq9pNSCxmAVIj6U+WZE55a1x6ToqZi4z2Mw0H
aHGo8qBZecCEEWw=
=/6Yz
-END PGP SIGNATURE-

Re: Seeking feedback on a meta package builder

[Sean Whitton]

Hello,

On Fri 04 Jun 2021 at 06:39PM +02, Helmut Grohne wrote:

> Hi Sean,
>
> On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote:
>> dgit wraps some of the existing tools.  While dgit is mainly for humans,
>> one role it can have in automated toolchains is producing an ephemeral
>> source package for the purpose of performing a build where the real
>> input is a git tree.  dgit knows how to convert various forms of git
>> tree into source packages and there are TODOs for some others.
>
> While dgit does wrap build tools and thus could be a possible mdbp user,
> dgit does so in a way that forwards the flexibility of those build tools
> through dgit. As such, it has a subcommand for each implementation and
> lets the user fiddle with the underlying implementation in the way they
> want without providing any kind of abstraction. I'm vaguely convinced
> that for dgit, this is best. An abstraction could be added as another
> subcommand if desired, but does buy little in the end. After all, dgit
> users tend to want tight control over the build and know their favourite
> build tool well.
>
> The intended audience for the abstraction on the other hand would be
> performing many builds in a mechanical way.

Right.  I was thinking that if you wanted to perform many builds from
git trees, dgit could help obtain the .dscs.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Russ Allbery]

Philipp Kern  writes:

> You know that this is a bad idea (granting sudo to apt without a
> wrapper). I know that this is a bad idea. That was my point. Plus that
> this is a very common trope in multi-user settings that you want to hand
> out some privilege to install packages.

Right, but this is a sudo problem, not an apt problem (which I suspect you
agree with, but I think it's important to make it clear).  sudo makes it
very convenient to give direct access to regular tools and this is almost
always a mistake.  As you say, that's been long-standing sysadmin lore
that arguably even predates sudo and goes back to limited setuid shells
and other tricks.

If you want to give people escalated privilege to run a thing, that thing
should be a custom-written wrapper that does only one thing and only does
the thing that you want to let them do, not a general tool that may have
other options or may change later.  And ideally you do it via an RPC
because setuid programs in UNIX are a giant pile of foot-guns.  Otherwise,
just be aware that you're basically trusting them with root with slightly
better logging and don't rely too much on the security boundary.

I think it's in some ways unfortunate that sudo has become so popular
because it makes this mistake so easy and so common.  I have found
privilege escalation vulnerabilities in almost every non-trivial sudo
configuration that I've looked at, not due to some bug in sudo but due to
bugs in the understanding of sudo and what it can and can't do by the
people writing the configuration.  It is *extremely hard* to configure
sudo correctly in anything other than "logged access to root" mode.

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

Re: Debian package manager privilege escalation attack

[Philipp Kern]

On 2021-08-12 17:56, Marc Haber wrote:

On Thu, 12 Aug 2021 13:44:24 +0200, Philipp Kern 
wrote:

On 2021-08-12 12:23, Polyna-Maude Racicot-Summerside wrote:

Now if people start doing stuff they don't master than it's not
privilege escalation but much more something like another 
manifestation

of human stupidity. And this, there won't be a number of article
sufficient to make people change.

[...]

This is only a article made to get people onto a website and see
publicity or whatever goal the author set. There's nothing genuine in
there.


I think it's less about human stupidity than about all the knowledge 
you
need to acquire (and retain) to securely administer a system. It is 
not

easy. The concern expressed here is pretty much common knowledge among
sysadmins of ye olde times.


I think the essence of the article is, that on some apt/dpkg using
distributions, a "normal" user gets sudo rights to do apt only (I have
never seen that on Debian, do we do this in some corner case?) and is
able to escalate to root from that trivially, even without doctoring
some malicious package, just shell out from dpkg's conffile prompt to
a full root shell.


You know that this is a bad idea (granting sudo to apt without a 
wrapper). I know that this is a bad idea. That was my point. Plus that 
this is a very common trope in multi-user settings that you want to hand 
out some privilege to install packages.


Kind regards
Philipp Kern

Accepted dnsjit 1.2.1-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Jul 2021 09:06:18 +0200
Source: dnsjit
Architecture: source
Version: 1.2.1-2
Distribution: sid
Urgency: medium
Maintainer: Daniel Baumann 
Changed-By: Daniel Baumann 
Changes:
 dnsjit (1.2.1-2) sid; urgency=medium
 .
   * Uploading to sid.
   * Adding watch file.
Checksums-Sha1:
 c51ed513feae75bb1e59279f88ae082a28c56aed 1997 dnsjit_1.2.1-2.dsc
 62a30307d9db48fef43001321c9a94dfec086d0d 1856 dnsjit_1.2.1-2.debian.tar.xz
 a253eee511c9bdeacb224996c28da1986c2749f9 6964 dnsjit_1.2.1-2_amd64.buildinfo
Checksums-Sha256:
 44d5172d73c8416ce286885e36451119b21611a1bb2002cbb699407654e723c2 1997 
dnsjit_1.2.1-2.dsc
 48b78cdbcaa401d3557cc6c10c304f315869883bce7bfc604d81fd2baf50e408 1856 
dnsjit_1.2.1-2.debian.tar.xz
 a86d2ceb4989a0b269d7459e4a1b0e369d724820915376d98a1768f10184cbd1 6964 
dnsjit_1.2.1-2_amd64.buildinfo
Files:
 f40dee285c2819dc164eb0e2044f6f8e 1997 utils optional dnsjit_1.2.1-2.dsc
 be7e67020c110bc25133c81c99c74e75 1856 utils optional 
dnsjit_1.2.1-2.debian.tar.xz
 e9c3560f85ce224d0da155206c8182fe 6964 utils optional 
dnsjit_1.2.1-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmEVWN0ACgkQVc8b+Yar
uce6ZQ/+I6TMZbogKIwSs6BUAPfKTAokFlUEg9jM2Lqd8moSVBU7jvLQwKT0cV7Z
Z/OgDhRYNg7q8+CfIPnWapUhoxUq5cKBzTTzTDGrogSDXjkwuXO7is4TF6CXXv9u
Hs2oBk+XfQXd7Io1TQArD5MNU3m1hA7T8Aaf5g49KnXX94o5mWkWqRlE2diwl+yy
S+G1ru0TGchEVUcUt3s88aUkb7pWOYQaQoVMwnR0zFdMr4RdaZxr+x2bkIR17c87
OHMt1LpYbGAE6qWITV5v6uBbE9L1xIlIs1dvupjZfNeCMW8AcRRbAj8t+WRoHogw
lzjA/iIJVnckzmcyNsDvt6s6HFqpvTUOsG5hrglWKz7eogi6Y2LI350bMnuiAOyV
GYyJ315KQxYdpfEwpo6v7xeNcuiRpn7T+eqN4JTDNRznrgEz2nLzNGQblF7emweu
KiaYlsJTRNYNvB6dqQVANk2gB82KM/LacO7lmCoTlnTGi1NiXQvsxY6tDJ6foxNl
V4z95XWm9KdYSWOR1LVV4+dVOXEIVvnjcgHlFDxZU4s7jo4iNoI0m9eQLc/O73up
Iy1LAAIOzdCT3QZLLJQ3d+Anj6AKysJ8ZGSsiSbL8ELtMdRwfHrrrY6dYWq8NLY9
ypyD1qjiYKxbBuqEGmL+Si9V1vVgEHaEJeFQq9jmrcnMbtnKPX8=
=vx0f
-END PGP SIGNATURE-

Accepted cloud-init 21.2-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 09:16:27 -0700
Source: cloud-init
Architecture: source
Version: 21.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Cloud Team 
Changed-By: Noah Meyerhans 
Closes: 991629
Changes:
 cloud-init (21.2-1) unstable; urgency=medium
 .
   * New upstream version 21.2 (Closes: #991629)
Checksums-Sha1:
 adc67f6ab8730c805c38f370fe1b807ff36c480d 2399 cloud-init_21.2-1.dsc
 1023e9149a109d7709fb94d551489aaa642fa0b3 1278878 cloud-init_21.2.orig.tar.gz
 d44737fcf376e46e4eb7f1ba18de503557a784ca 25000 cloud-init_21.2-1.debian.tar.xz
 5586b0f0b6c1b465c967955fd35f1e6fe5eb989d 6452 
cloud-init_21.2-1_source.buildinfo
Checksums-Sha256:
 4311388e4d1417609d5867129c27359b7125fdb0e151b4fffc719ec143b019b9 2399 
cloud-init_21.2-1.dsc
 b40862791eed9644fe735c886a7b4ed78ea4f298def295d82ac45c01278980c7 1278878 
cloud-init_21.2.orig.tar.gz
 d770023c391a8aded39ff4800b1b88d1babbe44df0c2872c931801d5a49d88f7 25000 
cloud-init_21.2-1.debian.tar.xz
 1c16aee065fcb6ebb0005c4fddfd6797f6a9666fde4054532fed295226f99397 6452 
cloud-init_21.2-1_source.buildinfo
Files:
 8da1c0bff0912401132ea249ba17681c 2399 admin optional cloud-init_21.2-1.dsc
 369278c57041da6dd9ce1e99577f809b 1278878 admin optional 
cloud-init_21.2.orig.tar.gz
 68b5d3952e36750db4a57b83624b4e60 25000 admin optional 
cloud-init_21.2-1.debian.tar.xz
 30485404f3e0d8935956ecfd226f0037 6452 admin optional 
cloud-init_21.2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE65xaF5r2LDCTz+zyV68+Bn2yWDMFAmEVTT0RHG5vYWhtQGRl
Ymlhbi5vcmcACgkQV68+Bn2yWDOLOg/+JwAARi18pXIHZCGeTYxch5qXyk/D3ek/
RVEHNSjAuaqLoLuLPMNVMAzeDGclIESNWLU8SQ5aAA8f+VKEl5mXTJVjzvlFNFI+
ebv4PiaUif1u9e7wqGK7uGfcRzN0aBjvKLL1afNmgcFgg5nB0dvthxQuTQlnBFbI
1GPqL0AG1WVa6aASASSOK9b6NPwsRBmiRE4opxLFrTj9N3diN+Ox/d2LhYvc2LXT
NRxqk+FPbizhWOzX7dlDgi4P3XNvtw493TtbuBVh9PH/6m7CPAuEyjOQ/bL0ElAf
uAf80yLw/VZ8d8RZPWJRxDwft0jOAzxr3zDLPn8G3jjN6IU+bpkB8LqKvp2D11ow
Rvi86dH3UmyWmwZ00mdoI012F6PGeJ6WitmzB00vKjgDJEZmfu+XzPZsxXh8jL9j
DY/2dY68u9ev9kPlGJ3Fu99cXOVmjDjff+CX6tlGP4sGhT3UxjB1gH2KaadI4Kd4
6yzPiI8j7lwb6kqN2zWzGvQILEpsUWzkDD4haZGKtlE9O0UgdleCVzTnNDKsRSsW
zKZk5Qk+yAQwJrukeNn4AJSaCEWaRExfJuj4WoV63ZJS3SWnKvo5dz2X6jYw0fmf
VUEJ9WXiXZ+oCCU1D9mEonpgN4er4nw1D26cM+QMAvq31XIKqI92i4zMPXUyPL/o
EOjXwRElKqc=
=iDB0
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Holger Levsen]

On Thu, Aug 12, 2021 at 01:19:23PM +, Holger Levsen wrote:
> if those users are not trustworthy than the bug is giving them sudo,
> nothing else. (Debian does not give sudo to users by default. The default
> is to set a root password.)
> 
> if you give someone a gun for hunting (animals) and that person uses
> the gun for hunting people, the problem is not in the configuration of
> that gun, but that someone.

after some thinking I'd like to s#hunting (animals)#self defense#.


signature.asc
Description: PGP signature

Accepted thunderbird 1:78.13.0-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 16:13:25 +0200
Source: thunderbird
Architecture: source
Version: 1:78.13.0-1
Distribution: unstable
Urgency: medium
Maintainer: Carsten Schoenert 
Changed-By: Carsten Schoenert 
Changes:
 thunderbird (1:78.13.0-1) unstable; urgency=medium
 .
   * [b4498b0] New upstream version 78.13.0
 Fixed CVE issues in upstream version 78.12 (MFSA 2021-35):
 CVE-2021-29986: Race condition when resolving DNS names could have led to
 memory corruption
 CVE-2021-29988: Memory corruption as a result of incorrect style treatment
 CVE-2021-29984: Incorrect instruction reordering during JIT optimization
 CVE-2021-29980: Uninitialized memory in a canvas object could have led to
 memory corruption
 CVE-2021-29985: Use-after-free media channels
 CVE-2021-29989: Memory safety bugs fixed in Thunderbird 78.13
Checksums-Sha1:
 dce2e6f4e698da89dcf7f7d38f6541c32858e262 8135 thunderbird_78.13.0-1.dsc
 7130b5de0441dc90423a12bc309409212b9a8dff 11808984 
thunderbird_78.13.0.orig-thunderbird-l10n.tar.xz
 16ae5818294529ff66df5385ea5cef0cb1f0f717 373488492 
thunderbird_78.13.0.orig.tar.xz
 f687dad4b0a9b5d1b351bb95f806cb052698df4b 706748 
thunderbird_78.13.0-1.debian.tar.xz
 5ce00085a93003e00af46bca1bb0bd95fefd87b1 35682 
thunderbird_78.13.0-1_amd64.buildinfo
Checksums-Sha256:
 9241f7ecd13b7b7281db2eee9bbc8e956e26d9b9d8fcb7863230102c2218828e 8135 
thunderbird_78.13.0-1.dsc
 551a1c5293c3060d21e19606f28941e47ffd48a14b31fcb441d96a965a9b346f 11808984 
thunderbird_78.13.0.orig-thunderbird-l10n.tar.xz
 9a7b9b97de616432e7728aaffc10205eb75ed20d0849f0a42352590dee42e488 373488492 
thunderbird_78.13.0.orig.tar.xz
 a7e43de737e9c70e557802905748a68dd3f0a0a9362224c9b5588520a52db23a 706748 
thunderbird_78.13.0-1.debian.tar.xz
 b7e53a201bdd7945036c179ca40eb3bec0c2a364a5e5a7b14dabc7166d3aacd5 35682 
thunderbird_78.13.0-1_amd64.buildinfo
Files:
 58f5253469962a089e23899de49af526 8135 mail optional thunderbird_78.13.0-1.dsc
 771af38d1e6ac67aa19eddedfcffeb40 11808984 mail optional 
thunderbird_78.13.0.orig-thunderbird-l10n.tar.xz
 b251540fd62106884eac627b0e17a087 373488492 mail optional 
thunderbird_78.13.0.orig.tar.xz
 6bdfda1920a28c1c4f3dbe4f98a98854 706748 mail optional 
thunderbird_78.13.0-1.debian.tar.xz
 1691a1a771b7c6c0cdb92e803573732a 35682 mail optional 
thunderbird_78.13.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmEVQZQACgkQgwFgFCUd
HbBUqw//ZZC2snx5iuYKWrst/1VTACxnx21RmK86LUbGNUFDSOGqVZ2OnlfeGjDy
YFYmad7uGByPsHFHX4vOctPoX7S+Gw6GowwJrBusPxIMTujd61kAc6eMqQ4rXzeO
PKC3SmqfUcVREV+AnoTKXyd1ek561GB7ihv0lbpRaLC9DwGH2eAeE6MFY/+qK48s
mlDS0hzHD9XIZBhepXy2IwZNnAGBeMpgc7pFoDAIK4WtWgi9ZVuNVoJpN5t6tfF6
kjpYxB4JOqzP0I2ICy3c9tUePW1EvU13MkhGt0LqVZAwEa6Z4Y7Z0BlsSP1yV2JO
30Z+pIIYz2yEFJJbGmISxh0uYE78LpOKZWOVTyyqMP8UUEEFeK0c9jU9p0ujW3ZV
emSvwrGl720aTggxu14y6stt0EE5w44MWhrtLT/dDRxaEkmJQktQKpZhJqpUQhF1
o3iOdSGiVmAnT3lzafOpIuFq9mDzHFwiypIlaGDheanHLja1N24Trcxqc3CYFvRE
8vTh6179NlXWJlj1avcNIih7eo9E3Qj1fYf9g77H3SCtEaYO3Dnxg+enPGseVH0H
Em56s6y13o3Ocleg3a58YwbZsKrH6VgCw/R+LOjstZUmqUg5veCsrN2Kj78czMwx
LLkSaS81lvMJCrYHA4gQ3LZbyjh/RHXnUkvmDgxybjUkf7Erpds=
=/kPA
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Marc Haber]

On Thu, 12 Aug 2021 13:44:24 +0200, Philipp Kern 
wrote:
>On 2021-08-12 12:23, Polyna-Maude Racicot-Summerside wrote:
>> Now if people start doing stuff they don't master than it's not
>> privilege escalation but much more something like another manifestation
>> of human stupidity. And this, there won't be a number of article
>> sufficient to make people change.
>[...]
>> This is only a article made to get people onto a website and see
>> publicity or whatever goal the author set. There's nothing genuine in 
>> there.
>
>I think it's less about human stupidity than about all the knowledge you 
>need to acquire (and retain) to securely administer a system. It is not 
>easy. The concern expressed here is pretty much common knowledge among 
>sysadmins of ye olde times.

I think the essence of the article is, that on some apt/dpkg using
distributions, a "normal" user gets sudo rights to do apt only (I have
never seen that on Debian, do we do this in some corner case?) and is
able to escalate to root from that trivially, even without doctoring
some malicious package, just shell out from dpkg's conffile prompt to
a full root shell.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Accepted whizzytex 1.4.0-1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Aug 2021 00:16:16 +0900
Source: whizzytex
Architecture: source
Version: 1.4.0-1
Distribution: experimental
Urgency: medium
Maintainer: Hideki Yamane 
Changed-By: Hideki Yamane 
Changes:
 whizzytex (1.4.0-1) experimental; urgency=medium
 .
   * New upstream version 1.4.0
   * Upload to experimental due to some lintian warnings that comes from
 upstream
Checksums-Sha1:
 21b9c8ab9ef8ee9768c1cfa563df96a40b4d6b7f 2076 whizzytex_1.4.0-1.dsc
 6b9196ffae44737151e7b37435fdd3105822f37a 1295301 whizzytex_1.4.0.orig.tar.gz
 622b48b3adaa5f0b3ce0589033d49d8ded2dce07 16384 whizzytex_1.4.0-1.debian.tar.xz
 7200d2cb9a7fc5720cd06c6506fbc3275e01f4e7 8755 whizzytex_1.4.0-1_amd64.buildinfo
Checksums-Sha256:
 e134d1853155968b501d032bd2dc832250f2ad212aa44dc5572b6cd805af0644 2076 
whizzytex_1.4.0-1.dsc
 f569144180487749022ba90f9f50a52c49d4fc06cba0ebfcbd2a6e35b31be687 1295301 
whizzytex_1.4.0.orig.tar.gz
 aa900d762cda4742d0052874d1867331c96a094f5b9555282805c926ec5bafaf 16384 
whizzytex_1.4.0-1.debian.tar.xz
 69392c1800f048faa452bac2cc8f77238f9c856d3871dae3cfd22826330d8ec7 8755 
whizzytex_1.4.0-1_amd64.buildinfo
Files:
 70c7dd103314fa81fb29997e5d0f9340 2076 tex optional whizzytex_1.4.0-1.dsc
 c393e6a91bd7b35a920de84f4207806e 1295301 tex optional 
whizzytex_1.4.0.orig.tar.gz
 eaa1bcac8f32818212174dd288a2cdce 16384 tex optional 
whizzytex_1.4.0-1.debian.tar.xz
 d34acc89b270fee38b0dba6aad29b365 8755 tex optional 
whizzytex_1.4.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAmEVPx0ACgkQXTKNCCqq
sUCbHw//dFv7BYG8EdpT8Zdr2lyW27l+A4G5tQjgxFuZmN1RJdIt7Qk5bpNCI8tv
zxOiySttTvIxQItk0fgiJPoqgLNhCdPToqH7QySvd/PPRpb355RRaXNDtOQr33o4
HU/JBGKx09MhSwtMCD33LAFuCxEIt66xNaAG2jI2REQuSvE2rp4boT6unYl1xz8E
YfQYhzzbRs6g8alzfWcYOiI8Zw8BhIaAKuuvG58QG/BNc2RXF3MkTT6DTtz0eCCP
5fRybWYCviK6y221+cGQvl5UwH8SyF3uX06jQEpYu6TUWJ09SZbCy5a6DDohXeJ/
rkRJBo/T98zbOPJ581o/aF8/vH0mFIgXIg8/UixIkoGIeJtk3JENLclrcfATBDwh
iUupM8p/G2xrKx7lWYtNtsSGGdatl42tBp+SqueVvfrWJyCSf8pEBMZG8AATnI1T
CUsNnOg5LhcJAcuyrj8U6mMkUASeev5MFcbtqDbCvoEMy4Ya6RvsiUKPG+xMWFBN
d5WzFwp3r4YTOMHiKCsVrJh+TQf3McCpM0J6sA3fgoc3LH1h8C8g712EBYMzY/4V
LuS1jNPW/I/frL7W6dvr1fJ3VeaEf+OC7xdu9RHMmdvPbMk6LCqXM9JicvEVk/ax
rj/quQBcZ8sQ3GP/u9ibkBBXWAZJqdeE+9aqbzt1MJWI/k8vPwM=
=pdyL
-END PGP SIGNATURE-

Accepted ruby-async 1.30.1-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Aug 2021 00:04:11 +0900
Source: ruby-async
Architecture: source
Version: 1.30.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team 

Changed-By: Hideki Yamane 
Changes:
 ruby-async (1.30.1-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 a9815505432f78e907e36d36282777b725dba2c8 2183 ruby-async_1.30.1-1.dsc
 56eed6af5f013d9b60f2358b53827e5ca9135a09 91936 ruby-async_1.30.1.orig.tar.gz
 5dd1c48e5ac11c59ab05783c7e01a1bb1f2194cb 2692 ruby-async_1.30.1-1.debian.tar.xz
 a2b121bc8a3cc7901e7f3a497225d9eee9a9ad8a 9328 
ruby-async_1.30.1-1_amd64.buildinfo
Checksums-Sha256:
 9d8a919425b6202ade700a2d35f02eccb5388068743ea721e4fb080c2ca8fba9 2183 
ruby-async_1.30.1-1.dsc
 a0f6c52ce37d9032c3fd371225cd3018bd84e4c09f30b6fcace9ca3656cc45bf 91936 
ruby-async_1.30.1.orig.tar.gz
 7f85cc93fa65be6949596815d480d5d41bbf51b58f185cf3c3b396904234e16f 2692 
ruby-async_1.30.1-1.debian.tar.xz
 d2a2a8903fdad835f4555b68cfb8c341f522453ae8760fe5b007960ce91c4baa 9328 
ruby-async_1.30.1-1_amd64.buildinfo
Files:
 4eda3850e48ed936c5bda744472552ab 2183 ruby optional ruby-async_1.30.1-1.dsc
 1e49322d84d375df96232413fa53866a 91936 ruby optional 
ruby-async_1.30.1.orig.tar.gz
 25233948f3fa9e10bee077d0265ecb3b 2692 ruby optional 
ruby-async_1.30.1-1.debian.tar.xz
 d25b2ecfeea0b61003db15ea8c567ae7 9328 ruby optional 
ruby-async_1.30.1-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAmEVOtsACgkQXTKNCCqq
sUBW3BAAgVE2d/d7przLyuUBww5Wge1vpY4ph9OtAadSipprjUnPTRvRcZmAnmE0
p7DDpcb8HPpqqL8fP+9dRYZnJk0BU/QY9OjQnn/R2FauKE8rw4a9h9GcpHzUhtTz
K3tzzdyX4HFPT620KfWVyXNaba8BX/FjAypE3xk6cG1dsIAAftXbCYryF7DN3Dwg
QcRu4dYObmrmFkjz3V1R1Oow0HlEXcBGgI/64RO+PdUsOAiX/ie+k/mZIZEEy7f7
I6K3q0E8B+YFi2IxD+2o9dAempH1KgkF+yaTcMD+984zP/jQy4TCtm7rvbqV2psA
j+nTSi7uzD23Kd4HsUxZU78H8CPew7SGKVxdnj8JypoKbF+nBUJjZFYdQ0D5sddP
F/0AHbwjsmt05I4JW77EDwgZhCtny68+Ry+sTgcyjtEUJy4UFaGDXhc/Te9/0V8y
Rwn5yN6m45JaNKDIgUp8QeVbVI/cpXYt1QVYVRiyXkARr652khAg7eEk5CPrQQpq
xDSq8x9FuoE3chxZr2CLGG2GivK0+BttYHH5S0dQ4kM5Tvw8LvM8pkWrpZHOxZaw
zyJh5aaNLV/tp5tIRDO+rLHWiZtAzF11h1290kPxcEyC5LSJCNqZwameME19cOHD
X9ArmocP2DQvt6lYroOm3KdNaOJF95Qp/dfUtKjvg++UD1hwbqc=
=AXTb
-END PGP SIGNATURE-

Accepted pywps 4.5.0-1~exp1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 16:28:15 +0200
Source: pywps
Architecture: source
Version: 4.5.0-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian GIS Project 
Changed-By: Bas Couwenberg 
Changes:
 pywps (4.5.0-1~exp1) experimental; urgency=medium
 .
   * Team upload.
   * New upstream release.
   * Refresh patches.
Checksums-Sha1:
 2abba8a3a7c1256b89344b906f8c063126996087 2391 pywps_4.5.0-1~exp1.dsc
 c20a3670cb25d2ee93fd7344650e73ec1628e05a 388429 pywps_4.5.0.orig.tar.gz
 0ab0d38c23f26d74972bc8c34478eea59764eb81 11964 pywps_4.5.0-1~exp1.debian.tar.xz
 2a1a3bafa7e03c95990a786e11387376464c06b0 12358 
pywps_4.5.0-1~exp1_amd64.buildinfo
Checksums-Sha256:
 314be4a5318737cd170478ad3a521b74ce9eb826a3f13c46fb35918a3d407f01 2391 
pywps_4.5.0-1~exp1.dsc
 c6acf89dcb6cb50695c1030ebba042469614e5e4ebe1925232eaf17bbba85c45 388429 
pywps_4.5.0.orig.tar.gz
 c38f035d5e1393bb159bc4b54ab7fc18f5d737c5f4987430d0f0b579fe9e3a2e 11964 
pywps_4.5.0-1~exp1.debian.tar.xz
 c58691d1fcc030469eb91f207f7e24a5572d271009e7e933df1db66a5c095904 12358 
pywps_4.5.0-1~exp1_amd64.buildinfo
Files:
 be249725967931c27ef0db87e120152c 2391 python optional pywps_4.5.0-1~exp1.dsc
 bfc97956126b3ef8cd2f236f646a761e 388429 python optional pywps_4.5.0.orig.tar.gz
 926fba74cff99833baad8d661dc84035 11964 python optional 
pywps_4.5.0-1~exp1.debian.tar.xz
 c435ca9b04f4c1301d82754b63edba52 12358 python optional 
pywps_4.5.0-1~exp1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAmEVMcIACgkQZ1DxCuiN
SvFJCw/+Iakjn8gHO0imuFQSq5F6T43GcD/eqHmOir5jWmhD8WDaFuHj+pbIXwdS
KlEWpmyeaacEHto1CSm+3SPeukhQciF6tZ0XHjpIv4OK//ruPyE/DSlKD0dxVz1Y
ouOBv/cIYwNsjWQBteDdd2Yk1sWmEXrs80Wn+nYapyFo7JgZhYIAHGEjhjOtmd1h
7jvN4zpLO2Ug2k+ExbHq50rXOEyBSKAB/czx+1bUZfb4czcXXSBPqrraMmKh816k
h7Y+UDRetWdx1rnUfNay5QDFrB56MZqa3+zJiD5/KhG0US8AEWr0QRs1eLpDHqPY
IdfK7NEKijkYfmDUcKiKDWgt5APR7hVU7vBujaTWe6zPy/kP6mooX4YUrnR9Bp/B
orhznBUbdo9+u+Jw6rT9/O50Xl19yuorZmcyey4hfeFk3i69P0/5+qMGlEH3y7Fc
c7HN8jQCNO0pvUrFgon1E3Q776X7psbDfM/VNB/pCIOAx/H4d6HIXxaTpdyY/Rle
ogHXzXaeCc5vY+n1kpnZRpOrwnHOndK+gW92bCeRGWYlGXY5Orjk94YOR2J1PATZ
S/hLyod/HyCyX35vECdSuM1LTr3oByYIZ+vS9Pir5KNMrj7jn6YSl9UDwMEOPzWN
RHpxm3TFITiLtoQr0+vNgRHaFRSC3w8rJ8qd6DskcrJMjFKlHqo=
=ULOE
-END PGP SIGNATURE-

Accepted ngspice 35+ds-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 09 Aug 2021 20:06:56 +0200
Source: ngspice
Architecture: source
Version: 35+ds-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Electronics Team 

Changed-By: Carsten Schoenert 
Closes: 984677
Changes:
 ngspice (35+ds-1) unstable; urgency=medium
 .
   * [53d3331] d/libngspice0.symbols: Mark symbols as optional
 Some symbols on ppc64el will get optimized out by the used -O3 flag on
 that architecture. Marking the symbols in question as optional prevents
 FTBFS for this architecture.
 (Closes: #984677)
   * [0d1da9e] d/watch: fix wrong substitution syntax
   * [92691d9] d/control: Mark ngspice-dev as Multi-Arch: same
   * [d71d66e] New upstream version 35+ds
   * [a0c11db] d/libngspice0.install.in: Be more flexible on versions
 Upstream now does a proper versioning of the libngspice library, thus we
 can't use a static file name any more for installing libngspice.so*.
   * [4e64882] Drop the current patch queue
 No patch queue is currently needed.
   * [f95af61] Revert "d/control: Mark ngspice-dev as Multi-Arch: same"
 The depending package tclspice for ngspice-dev isn't multi archified due
 architecture specific build, thus we can't set 'Multi-Arch: same' on
 ngspice-dev.
Checksums-Sha1:
 d745b09b049b3dde14e87ec012d1b3831ef8a470 2908 ngspice_35+ds-1.dsc
 bba236fbb13e458dc0f153221db6d7be244ed579 1137459 ngspice_35+ds.orig-doc.tar.gz
 932c8f4c5f9d3aaad05510fdad11757a39bbb04c 8177078 ngspice_35+ds.orig.tar.gz
 68de4d2abe9abe1cde99753847d20a62632f9dbb 23868 ngspice_35+ds-1.debian.tar.xz
 1bcf8f8341781ee0082c7900fc6fc4ebb9c85f91 14854 ngspice_35+ds-1_amd64.buildinfo
Checksums-Sha256:
 aacca66a3d1a74484c7913bc7171e05b229a313ae753badd1c5f25ccd4b2e31b 2908 
ngspice_35+ds-1.dsc
 c5682b203321c335d13377a81d1d398346caecc0b6ac7a31849b4d274059fdc4 1137459 
ngspice_35+ds.orig-doc.tar.gz
 fdffb66c6c35e7613bed496d154ecd022a9792373ac9500a0a3b8349c67fb1de 8177078 
ngspice_35+ds.orig.tar.gz
 424eef2bb72b53d5d6b1448652ff2fcf4d49a8f3099bb997aa0879352f9f8ea8 23868 
ngspice_35+ds-1.debian.tar.xz
 688fc9f8d78cc523228c0d26d48c8f7c4cd052b59d20e8beb9d3c9f5bdb1ee05 14854 
ngspice_35+ds-1_amd64.buildinfo
Files:
 b28eb6bbe58976a04c5941a9e3b24025 2908 electronics optional ngspice_35+ds-1.dsc
 3ee6830f82cce735d4fe750962cd2753 1137459 electronics optional 
ngspice_35+ds.orig-doc.tar.gz
 7d2c0ed35ee4b14b4b03c2ec18cbc1e4 8177078 electronics optional 
ngspice_35+ds.orig.tar.gz
 032fc8393efbe63f3ebc41060d1908cd 23868 electronics optional 
ngspice_35+ds-1.debian.tar.xz
 e8a492e2c8cc2edd0f2a2932e9edf775 14854 electronics optional 
ngspice_35+ds-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmEVMjcACgkQgwFgFCUd
HbBSCRAAlS979ZZ5hXq0imvgbF9zrkDI+VsxER7KXHux3sWg62eiQF+9thUHZLPW
LaZvYIh5OapullN599cU9S83y4QYcT3LmQ7z6MhxBTsoppNWui3Ub4jifiYLz0gx
QJ3qT3iLMnfCYtLe93fFZYtxfwhrOYU8tdod0oqQyPDtZlbwVMMqW6eCF+r0odFZ
dah0vqqMHHedVGcSl8j/WeuOOD1zGG6e/hmZuA2JUUGqFEM+PFGpx70ntaJPxktH
X20262Iq2PY2d5IZ+ZqqYc3y2CUgmO94QpNNWS8c4Bdr3SjfLyWFpm97I3zFRdxL
1mJ7QAwBa41fFbnbjfr5pfLiRKSchcX2QOt7vQKU4R9VnjLBSUOzo9Azgg+xo3QS
iILTTMZokhybHgESjVf1xFe8ivbm957RW8QSzV9zAyZaHi1VpcR1cFiSqJRQRAse
Any4T37lwxqtEi1JjjDkRRBUSKn2nLx6RvJaCQMBBryWpSbT2uIXAACW2fVcoNTB
VPNdpXs+MKRbPTRk+UKSDPlE3/UHpug0M93h7m+Bu+6MRg8+mVej/TG0Et1ac9WV
pJmEkb/FqYgKcSbhqrqS59DQI3iBWlf+2AS9Dab1Bm+nsMq6ZRsC2u889ZeSIKYd
cXtQT5awytO8gOnKEM18GRbHmy7zKTChGnmZICx+caPOP4CT2kI=
=8Bt9
-END PGP SIGNATURE-

Accepted ruby-loofah 2.12.0-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 23:02:54 +0900
Source: ruby-loofah
Architecture: source
Version: 2.12.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team 

Changed-By: Hideki Yamane 
Changes:
 ruby-loofah (2.12.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 2.12.0
Checksums-Sha1:
 24240031d84c7bea55dc923381eb8dd982714353 2168 ruby-loofah_2.12.0-1.dsc
 2a2c71e6a48f81bf3495140346a4ecf09250c0fd 22480 ruby-loofah_2.12.0.orig.tar.xz
 7c8a669853463a295535975b93ff81f6ef85442d 3804 
ruby-loofah_2.12.0-1.debian.tar.xz
 bd707958ad38258cb62050ee16f0863c5a1f65fe 9111 
ruby-loofah_2.12.0-1_amd64.buildinfo
Checksums-Sha256:
 1ab14e96ba4b13d24effa15d63854b113590411e8b9f882beca43055bdbd0c80 2168 
ruby-loofah_2.12.0-1.dsc
 e2e55a323d56613982524307efc4c86d91bacc5bf9a00e90ac9c677e4fe3a9e9 22480 
ruby-loofah_2.12.0.orig.tar.xz
 dff45718117ccb8b735dfc7b54fe6beec9757812ae99c9f664d57d17b23f68fd 3804 
ruby-loofah_2.12.0-1.debian.tar.xz
 48c549f0f130a133e1ae77eb0cbca8ff7d9e56acb60516fcd647a04c70ac77af 9111 
ruby-loofah_2.12.0-1_amd64.buildinfo
Files:
 bb4db5ddd0e50c33e3813049af06e407 2168 ruby optional ruby-loofah_2.12.0-1.dsc
 7ac177fd09cf828666bb353accbe9805 22480 ruby optional 
ruby-loofah_2.12.0.orig.tar.xz
 2c8db9fb2e620e807f726769052273b7 3804 ruby optional 
ruby-loofah_2.12.0-1.debian.tar.xz
 ab1d3385b867596bcd299f98f70db5c2 9111 ruby optional 
ruby-loofah_2.12.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAmEVLT0ACgkQXTKNCCqq
sUAJ4g//ZknUjkPlebNDkN1Xw877sg6cerldyyVWVmdf08KhisIpSfRzwvaVGA27
icHXLvihNQ4XLNzze5EOHdQOM/ALdvK6vrSEq0bZ5sKe4RIcOARt1Ug8LeYJKC9f
m5Zf8V2foYLGGr6zdQtEiIcGVOZaoVQE0yHEKEEbNAWaI635Cyx0SA7Mga63h+se
bHJFCHcrMhEgrdZErmZLUEUZj/VugToLrhN+A7c0k7eQdGx3d1CCbCOqnqX+li4s
ykHcjTtPhvShG/EW1k1woBNgV2l0EWNNQUKqEIiLlN8YgOe+mQWa1aS9J5mkjUFk
euTFNQ/IpAxLO0aQhrAyYzD4sfVr4uFZgJ/o6Qs6H7DHXSnzl583xmVu7vnu+ZS7
kPQI0CQIVGtDIgjUNdz9L7FUM2vHXjVaTJZjJEi0IQZ6CIkCVhnNnx/nYbX43pPl
X9LrX+aWXgVr0ag2oayDj9GyWH6hWZqF3KpifIyaTjdgReJTeirkx3prwpcoGPfj
IAhDbtqcnUA9PQ5OCkbu4KZk5QIi/XwqCRv/oGVg7F7gM80fgEW4hd9GA14/9kJ+
9bbtiBOhHsWZGO8e0eodVXggfQN0VlUnzFmhWqlFJCEc3gs7kZanvecJpQbL0JoR
hH0nBVTLfKnz+DMIgYPFmU2AFq3D/N74fWgWQ81w5tBGKMf2zMA=
=m640
-END PGP SIGNATURE-

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Romain Porte]

Hi,

11/08/2021 16:08, Vincent Bernat :
> I think we have more systemic issues. I am quite impressed how Nix/NixOS
> is able to pull so many packages and modules with so few people. But
> they use only one workflow, one way to package, one init system, etc.
> Looking at Arch, one workflow, one way to package, one init system, etc.
> Looking at Fedora, one workflow, one way to package, one init system.

I think this is a major point. I am a new Debian contributor after a
good time of ArchLinux PKGBUILD writing. I find Debian technically
superior on the packaging side, and would not trade it for PKGBUILD. But
there are so many ways to do things. After a lot of exploration, I have
found that the tooling that I was the most comfortable with was:

  * Salsa VCS
  * GBP for git + patching (+ DEP-conformant branch names)
  * dh

However there are so many other ways to do things. Some packages are not
on Salsa. Some packages use manually generated diff files. Different
branch names everywhere (debian/latest vs. debian/master vs.
debian/unstable vs. master…). I think progressive enforcing of a
workflow would help new maintainers to not be lost in the packaging jungle.

> I still trust Debian to be the most technically excellent distribution,
> but that's not all it makes to stay relevant. My point is that it would
> help to reduce the technical liberties we take in Debian. However, I
> don't think that's who we are.

Maintainers like their freedoms, but enforcing some tools at some point
could make it easier for everyone to contribute and not relearn the
packaging process for every package, because currently every package is
different. We are getting there by looking at the number of "3.0
(quilt)" packages and "dh" usage, but when a package does not conform to
this norm, it triggers a mental freeze on my side (and I want to migrate
it all to dh/3.0 quilt etc.).

> Let me take again the example with Nix. Anyone can do a simple pull
> request and gets its change accepted. Each package has a maintainer, but
> the ownership is quite weak. The maintainer may say no, but if they are
> just busy, someone else may merge the change if it looks reasonable.
Maybe the interface helps too. With a single repository, everyone can
see every pull request easily. For Debian you would have to monitor all
repositories/bugs for NMUs waiting.

> In Debian, we have many workflow (BTS, MR to submit changes, Git, not
> Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to
> package (just one makefile, old debhelper, new dh), many init systems.
> And the ownership problem prevents people to help from time to time.
> There are so many packages I come accross that could just be updated to
> a more recent version and looks like semi-abandoned but I just don't try
> any more because there are so many ways to fail.
To me the problem is not to do the technical migration, but to make it
acceptable to the current maintainer that will usually not want to
change their workflow — or not answer at all. One issue is that you
cannot repack everything and propose a NMU, because it is a major
change. So what do? Apart from RFS or co-maintaining, I do not know how
I can help "modernize" these packages. If I propose it as a .patch in a
bug and it is refused because the maintainers "does not like 3.0
(quilt)", I have lost a good chunk of time.
> Today, it is very difficult to only use Debian own packages. We just
> tell people "just add random repositories". Nix and Arch are able to
> have almost everything packaged. Nix is able to include into a single
> workflow most other language ecosystems.

We could have the same in Debian, but the constraints of "build from
source" and lack of interest for "contrib" and "non-free" channels is in
my opinion severely limiting the number of available packages. AUR
contains many packages that are not open-source nor built from source,
but users are happily using them when they want to.

For example for Spotify or VS Code (or many other external, sometimes
proprietary tools) you need to add an external repository. While on Arch
I guess you would use AUR. Why could not we use "contrib"/"non-free" for
the same purpose?

In the fonts team, it is increasingly complicated to build fonts from
source because they use so many javascript dependencies. I could propose
to ship the final .ttf/otf fonts into "contrib" instead. But given the
review duration for getting into "main", I guess "contrib" and
"non-free" are worse in terms of given attention.

Looking forward to pursue the discussion.

Best regards,

Romain.

Accepted libpdl-linearalgebra-perl 0.21-1~exp1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 15:46:58 +0200
Source: libpdl-linearalgebra-perl
Architecture: source
Version: 0.21-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Perl Group 
Changed-By: Bas Couwenberg 
Changes:
 libpdl-linearalgebra-perl (0.21-1~exp1) experimental; urgency=medium
 .
   * Team upload.
   * New upstream release.
Checksums-Sha1:
 d6fa36262d5141baa96b0b78d837b6b06f004cb7 2260 
libpdl-linearalgebra-perl_0.21-1~exp1.dsc
 d6625745c8db7d5ce039cb5994884f4af5a72503 169451 
libpdl-linearalgebra-perl_0.21.orig.tar.gz
 6e582c64f3f681a313b39eb3657d8f3393db4a96 6324 
libpdl-linearalgebra-perl_0.21-1~exp1.debian.tar.xz
 a50bceb108bac30be851fca2b88f171d88faba7b 7735 
libpdl-linearalgebra-perl_0.21-1~exp1_amd64.buildinfo
Checksums-Sha256:
 d3d97fd6c7d803cc40b38996fdb4aea3b9f2cc587655198436c3eda33664a0b6 2260 
libpdl-linearalgebra-perl_0.21-1~exp1.dsc
 57c5738cb16f1da474bf6a27f1650639a062a68843d36597a4cc310b73629e94 169451 
libpdl-linearalgebra-perl_0.21.orig.tar.gz
 543993ce348eeb861582401e90c99dd7aa1c110f7a7c1c7bd4de16de5cdff325 6324 
libpdl-linearalgebra-perl_0.21-1~exp1.debian.tar.xz
 3aecd616be2c332bde3b618786c72d9b2c9aae90265c6080fb5448bf1a6ac8ba 7735 
libpdl-linearalgebra-perl_0.21-1~exp1_amd64.buildinfo
Files:
 5116954cf8e3db0979a269663a544ad5 2260 perl optional 
libpdl-linearalgebra-perl_0.21-1~exp1.dsc
 2a930b2ed236f4b1f5dd17efd77d3a6e 169451 perl optional 
libpdl-linearalgebra-perl_0.21.orig.tar.gz
 840fbd2a55e04ef053f23f6838f40d70 6324 perl optional 
libpdl-linearalgebra-perl_0.21-1~exp1.debian.tar.xz
 626e9934d16a07670c6945f0528fd356 7735 perl optional 
libpdl-linearalgebra-perl_0.21-1~exp1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAmEVLJQACgkQZ1DxCuiN
SvF8HRAAtrZ7+bhd4yAMeLmZxHEtADvs/oEUZe7y5AvKs5mykRhWQlebE3yditdJ
gRwYpp/fjSVqDPpr9AeAHehUy2ongNtZ5wWV94DiOkF8v3tyGCs3cgHLMgGSKr9N
aFPbusIwqheR97PdMNtyrEHCo9wsZn1nkyePYbogitZjVLLPVAqpwIaSQO1EB3uw
Vle61tubU3v5a4xDVVJT8ubNXHXL5g1Vy+Wqtz+tBpQPrkbDlTC3+Zwdk8w1UsJn
M0Xxp1uv0zowNK6W95+MwUQYJoxTNfRKIvdFVIxhxhRTPuhgmL3Th0ZOAmkfTEw1
j+VF1xM8FzW8d/VenBec/FxgTrVV4a1EqEiq6JYbGZuX2xgt7hHneqDmxb3gnnXr
4dkiOsCQgdJFu8OefR/1BSRk1j8fMm6V6FlsUxU6awffK7uavshEiBUw9Q8UprMS
42oLJrT3/W8rGEU6FTeEJQuX9YVR0oUTD8w2ghr6f0cISHnoQzzanCAoZt1j4b6k
eplGJP9/E1/GSzK7piBvlIOsxuARnMP+NpmeJnq9VkMpr1IFG+TyFpCTrubLKNQe
33DRfasAQeuhDmD80QsQe9k+FpNI2377FYnQfLeRWpVncAmbXFpNj2J3fZpC390H
lHcjKgEMtYW0nOxBcSNJftxdciZF5RhgHmJhz8PGA7naCj9GsNY=
=m00o
-END PGP SIGNATURE-

Accepted libpdl-graphics-gnuplot-perl 2.018-1~exp1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 15:37:08 +0200
Source: libpdl-graphics-gnuplot-perl
Architecture: source
Version: 2.018-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Perl Group 
Changed-By: Bas Couwenberg 
Changes:
 libpdl-graphics-gnuplot-perl (2.018-1~exp1) experimental; urgency=medium
 .
   * Team upload.
   * New upstream release.
Checksums-Sha1:
 c28e3f532ae9ad2ab8b6d17ab6648496755e704e 2329 
libpdl-graphics-gnuplot-perl_2.018-1~exp1.dsc
 a9e3d0746a646dbb08561355aca36c3088229620 151676 
libpdl-graphics-gnuplot-perl_2.018.orig.tar.gz
 462096ec303d000127c5b860fea58862a260a479 3280 
libpdl-graphics-gnuplot-perl_2.018-1~exp1.debian.tar.xz
 45ee8ce1bbd6d6884bd462fdf62406cc20b5b386 12085 
libpdl-graphics-gnuplot-perl_2.018-1~exp1_amd64.buildinfo
Checksums-Sha256:
 9ae85cb32a3c6dadf6abf9242aff99c036101f629d1a29e089c07f47f92163a7 2329 
libpdl-graphics-gnuplot-perl_2.018-1~exp1.dsc
 416ec1177fe4aa0f3cd2d7d804e01a0f7c7c8ac77005a6876ae3c96e316d0d59 151676 
libpdl-graphics-gnuplot-perl_2.018.orig.tar.gz
 9646d52f2d4b50da07440a8846fe93df5d5d498687a41ed15f3592ef67f27305 3280 
libpdl-graphics-gnuplot-perl_2.018-1~exp1.debian.tar.xz
 5eaf66445ba6cc59ecf5023e57583217c8647f48792d424fa18fb35b213ebfcc 12085 
libpdl-graphics-gnuplot-perl_2.018-1~exp1_amd64.buildinfo
Files:
 8349c4b569464a650070037b6915c623 2329 perl optional 
libpdl-graphics-gnuplot-perl_2.018-1~exp1.dsc
 6bc2415f0a70926cf64fb56d378d162b 151676 perl optional 
libpdl-graphics-gnuplot-perl_2.018.orig.tar.gz
 80e1a93baa60cffb1c7d0e5126306648 3280 perl optional 
libpdl-graphics-gnuplot-perl_2.018-1~exp1.debian.tar.xz
 ff301835f81abd12d0132ff8353339bc 12085 perl optional 
libpdl-graphics-gnuplot-perl_2.018-1~exp1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAmEVJbAACgkQZ1DxCuiN
SvE6vhAAlMlLd04n4oVibI61vshvnKoHLXvCVhrFigretuG4+ZHEfHk9nt7KZGyg
s0fMqQG91r/GbWxz8DtDPYSIdpLu4DnoapJUcXQrwanGGKx7yXBnXj0jRpGbXZIA
fYTkU13ZZqjIOStsycLwyPbNlgv9gAQUWegzHV6W5C27wGYOj3aLkoZkZkn8tmfd
rx6jfJnb/l6y52phGD7QpZsC7Q9HCeACxDBqIq0cmnwavNMeEZIqfUFChO8p7GbV
h9ffBAeqbiJ1xsUpDTEOJSUQzGAiWVbpVUu58sDUhDTiPNyY09xb9SUw3Q+Bm8Zx
5TJurEgXZXRGnfiqfXEnQj9MwwN0kA/3FRsaPYtlloitjM1co6tBfike1YsW0yXI
x95+Xij9TxmkhOhvyVHNVQjNqsfIwfNYoNu1PRv7rjMR0W+btmBNLgNVixh1hY/z
nD+0xkw3GclaqvZzV6VU85jDmlvxv18AxWt2kcipFwgfkTMKdgeChIKjXP3ukl9D
vuywJZiDzJ8lY/XfSfj5QZSv205Nh7eU/7/ztO+6fX8g+gYK9m31EOI9CkjroJ8K
mRthF3aCt5TVsMgO6uKfYDJg8P/89rFz2optf6pVvzX05H4po+0faHwFqMfLMpxy
wBUOjPy1MoHXGgdVkcrCYmxVopSc+khA955QGiQqGbDaqM3n7RQ=
=8yH6
-END PGP SIGNATURE-

Accepted imx-code-signing-tool 3.3.1+dfsg-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 12 Aug 2021 16:02:12 +0200
Source: imx-code-signing-tool
Architecture: source
Version: 3.3.1+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Andrej Shadura 
Changed-By: Andrej Shadura 
Changes:
 imx-code-signing-tool (3.3.1+dfsg-2) unstable; urgency=medium
 .
   * Unbreak the scripts.
 Thanks to Sean Anderson (patch taken from Arch Linux).
Checksums-Sha1:
 fed5d934a1b9034ee5af2b7faf8506fc7586d3ee 1536 
imx-code-signing-tool_3.3.1+dfsg-2.dsc
 1293ca92c5f4c52ba5fc021ddd69627afcd6f335 4436 
imx-code-signing-tool_3.3.1+dfsg-2.debian.tar.xz
Checksums-Sha256:
 8c2e3eb6c5a8c22c844db4ff9bff728ccc20fd13e1c6598ab61627e17904d4a6 1536 
imx-code-signing-tool_3.3.1+dfsg-2.dsc
 63c19ed657bb4d3f19aeb2805620e415a0c085c4108e44b0889ea3f0cfa4fe65 4436 
imx-code-signing-tool_3.3.1+dfsg-2.debian.tar.xz
Files:
 caaac8d16f72405b792ee383fe3d6685 1536 electronics optional 
imx-code-signing-tool_3.3.1+dfsg-2.dsc
 b97c1b0dd6defb6685fc21566cb708e1 4436 electronics optional 
imx-code-signing-tool_3.3.1+dfsg-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iHQEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYRUqQAAKCRDoRGtKyMdy
YWthAQChbvwqxdn9T9QneSP+i8ulX2OU0zyIaFc91ksaasgr1AD47mOb6pQGbuB4
cM51rcPvV99Fs+H+RxVRAofnn6QaBw==
=tIU1
-END PGP SIGNATURE-

Accepted imx-code-signing-tool 3.3.1+dfsg-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 12 Aug 2021 15:10:25 +0200
Source: imx-code-signing-tool
Architecture: source
Version: 3.3.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Andrej Shadura 
Changed-By: Andrej Shadura 
Changes:
 imx-code-signing-tool (3.3.1+dfsg-1) unstable; urgency=medium
 .
   * New upstream release.
   * Drop patches applied upstream.
   * Update the copyrights.
Checksums-Sha1:
 997f5a7341e3d170e8fc4b5a2404133cac257684 1536 
imx-code-signing-tool_3.3.1+dfsg-1.dsc
 04dc47c22cc0b83f7ae0f6f2336c45c09e866bc8 3638096 
imx-code-signing-tool_3.3.1+dfsg.orig.tar.xz
 c40bdbe96e75b352e0394dc5dc3972a5b032fec5 3448 
imx-code-signing-tool_3.3.1+dfsg-1.debian.tar.xz
Checksums-Sha256:
 06c13a10136255b6f39f5db7db8c74471af8aa8c86c64c7d71e8c3b5e8675ede 1536 
imx-code-signing-tool_3.3.1+dfsg-1.dsc
 1f804b078d45344f099b543bde712c205ee80a4b231bff99f68c625e60ced9d1 3638096 
imx-code-signing-tool_3.3.1+dfsg.orig.tar.xz
 22fb724f89e8d2a746acd6adaac11828100a7d02df11fd49120ed34ffd68dc01 3448 
imx-code-signing-tool_3.3.1+dfsg-1.debian.tar.xz
Files:
 c80f47767870e39957c105445b47b92a 1536 electronics optional 
imx-code-signing-tool_3.3.1+dfsg-1.dsc
 eccfdac7f1798680638f45a0310f9851 3638096 electronics optional 
imx-code-signing-tool_3.3.1+dfsg.orig.tar.xz
 b0aba803982a6cb55ea5c540680f8d1b 3448 electronics optional 
imx-code-signing-tool_3.3.1+dfsg-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYRUitgAKCRDoRGtKyMdy
YQHWAQDksDjq7Fcbfd8Oi4NrO41qn8WVK9J999G2rYiLzANYHQD+KlSXo6RuYBTi
U9ymbhtTxVAftDOuD8hRk1X9jVAqzAQ=
=WU0S
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Holger Levsen]

On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> Would you agree that there is an issue with sudo access that is enabled
> by default on most Debian and Debian-based distributions? The bug may
> not be in apt, but it definitely lives somewhere.

if those users are not trustworthy than the bug is giving them sudo,
nothing else. (Debian does not give sudo to users by default. The default
is to set a root password.)

if you give someone a gun for hunting (animals) and that person uses
the gun for hunting people, the problem is not in the configuration of
that gun, but that someone.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Change is coming whether you like it or not.


signature.asc
Description: PGP signature

Accepted postgresql-13 13.4-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 18 May 2021 13:56:18 +0200
Source: postgresql-13
Architecture: source
Version: 13.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 
Changed-By: Christoph Berg 
Changes:
 postgresql-13 (13.4-1) unstable; urgency=medium
 .
   * New upstream version.
 .
 + Fix mis-planning of repeated application of a projection step (Tom Lane)
 .
   The planner could create an incorrect plan in cases where two
   ProjectionPaths were stacked on top of each other.  The only known way
   to trigger that situation involves parallel sort operations, but there
   may be other instances.  The result would be crashes or incorrect query
   results. Disclosure of server memory contents is also possible.
   (CVE-2021-3677)
 .
 + Disallow SSL renegotiation more completely (Michael Paquier)
 .
   SSL renegotiation has been disabled for some time, but the server would
   still cooperate with a client-initiated renegotiation request. A
   maliciously crafted renegotiation request could result in a server crash
   (see OpenSSL issue CVE-2021-3449).  Disable the feature altogether on
   OpenSSL versions that permit doing so, which are 1.1.0h and newer.
 .
   * Remove obsolete #dbg# and #PIE# code.
Checksums-Sha1:
 ac840b1a42845c35d14529614317addd6c40725d 3655 postgresql-13_13.4-1.dsc
 92146ec62ad80e8f5d2959b5cc1766311dc00d64 21157443 
postgresql-13_13.4.orig.tar.bz2
 acaa93cdba02deac334514b171f8db5a4ce95941 28080 
postgresql-13_13.4-1.debian.tar.xz
Checksums-Sha256:
 e49950fb8d2865c45f3a57d75d875499974b88203118e7da335957cc9b9ea0cc 3655 
postgresql-13_13.4-1.dsc
 ea93e10390245f1ce461a54eb5f99a48d8cabd3a08ce4d652ec2169a357bc0cd 21157443 
postgresql-13_13.4.orig.tar.bz2
 a6421ddc8bf36674087e352570c459193fb7196188bcfa1ab574fd5a735c88fb 28080 
postgresql-13_13.4-1.debian.tar.xz
Files:
 6e042cc5d2ff2ef2242a64900a6b891a 3655 database optional 
postgresql-13_13.4-1.dsc
 7bda65a37c46b8b2c1933d9d1cd677f2 21157443 database optional 
postgresql-13_13.4.orig.tar.bz2
 f1a50ee5562e977a1160187f37bf5262 28080 database optional 
postgresql-13_13.4-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAmEVGS8ACgkQTFprqxLS
p67NIQ/9ESUwDl7gClKEynkmpnStlCwcwhqDRY1texRvmhoMHLJ889scZqcJa6kO
mby7QYXTNFqKOQmv5iQzVvWA35d//uw+kjUAWEHy785HwMdYC60qF3cvBz3oth98
lQXiTTMm8x9doJfraNYXf5AscHQnF2EeZe5j/VEIpSAsgpOlpHUkOh/YPyWO5SN8
Snb3doNV34pJLUL2IGU6DZTt9JMO5ZUluYdyEZk1KDF+QHGNKBWeOLGLABMGgRdX
G9GD3CayHCi6o8zD6rK+gPXfZkvLrY+MBL5Lbp+cOJntG17BDDjxnLw3jH4tdGhX
mjeFBbX6z/ZEjKac/pRvkEQMqmuAiqmoQiwlO+FF11ieZzyDbRMuVgeDdEb6abB0
H6fTC3lU+7Dm8TuMu18w77k/QfrNYDypk454u2wPIFp3bRwArjD635oSn82ViLo/
VYlHijqdqCCCcJES4p5MGl0yUGaXJGew8OuZBzExd0q/VQI0FQDtwFwO+1ZzJjzD
xeRRkgZ+dfqnZO/PsHsncS63ZwrW7NC5A2G0otPtmiRQrdMDFcQ+8xrZQUs9J+yf
4vrZjlQtfF3LuqW7MswPiCc1gxdGPRFGsvFg593Ruaua6b7zLmgil6/oF7heTyDM
4WXGVc0GgY9W+ovpx6DlGu/rAwwciNJNzN/WJaj40ZxmScA+b1M=
=KFFh
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Paul Tagliamonte]

> The focus of the article is "sudo access *only* to apt". When we talk
> about unrestricted sudo access it doesn't even make sense to talk about
> privilege escalation because unrestricted sudo is by design a privilege
> escalation.

Similarly, sudo access *only* to bash enables execution of loads of things.

Hand-installing a user-provided deb could do things like put suid root
binaries on the filesystem, too.


  Paul

--
:wq

Accepted postgresql-14 14~beta3-1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 10 Aug 2021 13:11:12 +0200
Source: postgresql-14
Architecture: source
Version: 14~beta3-1
Distribution: experimental
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 
Changed-By: Christoph Berg 
Changes:
 postgresql-14 (14~beta3-1) experimental; urgency=medium
 .
   * New beta version.
   * libpq5.symbols: Add PQsendFlushRequest.
Checksums-Sha1:
 4bf345294f42c42fb9b5d5b683bef1cacf229d37 3696 postgresql-14_14~beta3-1.dsc
 d8e1e782952c118e09e74de88605e51a521fdbab 22584314 
postgresql-14_14~beta3.orig.tar.bz2
 1f17b536502bcd3ee4de49f10d715aad0f085869 24436 
postgresql-14_14~beta3-1.debian.tar.xz
Checksums-Sha256:
 e0f8574c50f3a15da1c42d3d7d9fc439012937905f9918aa8e190007ec876e44 3696 
postgresql-14_14~beta3-1.dsc
 2ea265980193db70106576201a2fee5b2d72bf9890d3911ddd374d4830624bfa 22584314 
postgresql-14_14~beta3.orig.tar.bz2
 78d37f22871d21ab091c75b1b30bd002b365aa35b2b13c81ec465cd79eb05f5a 24436 
postgresql-14_14~beta3-1.debian.tar.xz
Files:
 06e931c1cd1fa7012bd9f2bc07c8d6d9 3696 database optional 
postgresql-14_14~beta3-1.dsc
 83f74c2cbc5f32ecd4dc5e41c23b90f6 22584314 database optional 
postgresql-14_14~beta3.orig.tar.bz2
 ce7710fe39482528df972d9d370eb9a4 24436 database optional 
postgresql-14_14~beta3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAmEVGAsACgkQTFprqxLS
p64fbA/8CRsYy5jUaMXr6zQU6PrvZRNK3CuQUNfYlu2QxYm2Et9IAVUT+Byet5P7
rw+rhMOXMaM3oIY1c6J6UKt5ElVwSp8QJ2Lvd7G4uPcC/z49dPJkMC5D8UAp172x
uogs4/Hwe8UL3bfY9Blvafpmq+FvJm5qSF9fdrDvWDIbHssyKAGsNlygStvLjq7g
0HyeL0F/xgL96iFw016a97aRAdILWL1bMtuLfkVBGx2ZKQdNhD6UVa9uG2X1ZC7S
rpx4ErMBzaeObmgeiOhsGB4nc36uNKeQ8zxiEXm9t2KCvL8F/sY+KR4hEdZd0opl
f4qEx9ll0KKwKzeERHwoFJAbGmKK0D5zyB8YGpzFkFobfOqnfuklAVHQgPZYBlmo
2ouEW5gsSzBVKlq4gyiUKM8ChU5ejdk6vYOMr0EbyE9ohOujGu5MIMJolOI9y3Kx
Gaffgq9oVUw4BY/u/N1Cv0V18nktQA63IGwrPxfVcTivZAkuVaOgljFgUC0ZKT94
ey+KNxesp0F/7QDsoC97dwZAbKyy0OJJSmzeLDy9K4D+McO0TmpXyrWEUBjpI8EK
PUW+TBwojscaSzaoiAT0AN/szUxEAg18jHm7mrtWz/EM4Kc4KkTQlt+QTU2p019o
vZrstOb2R0z3gONGxoGoZ0p3b2lZZzY4u4ytSC7ez+lHJRrCB8c=
=WPP0
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Andrey Rahmatullin]

On Thu, Aug 12, 2021 at 08:35:42AM -0400, Kyle Edwards wrote:
> > > > I just ran across this article
> > > > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> > > > the attacks on Debian 11 and they work successfully giving me a root
> > > > shell prompt.
> > > I don't think calling this "privilege escalation" or "attack" is correct.
> > > The premise of the post is "the user should not be a root/admin user but
> > > has been assigned sudo permissions to run the package manager" and one
> > > doesn't really need a long article to prove that it's not secure.
> > I think the article is interesting nonetheless. Some people may think
> > that granting sudo on apt is OK. In the past, I think "apt install
> > ./something.deb" was not possible.
> Random thought: could it be possible to restrict non-sudo users to
> installing packages from repos that are signed by a GPG key that is already
> trusted by the system (the Debian archive key)? 
Via some wrapper maybe? But at that point just use PackageKit?

> That way this attack could not be carried out. 
Only the one that relies on package content, while there are more ways to
ask apt to run a process, as listed in the article and in this thread.

> Then add a Unix group that allows apt installation from
> trusted repos, make apt setuid 
Please don't.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Kyle Edwards]

On 8/12/21 2:32 AM, Vincent Bernat wrote:

  ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:


I just ran across this article
https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
the attacks on Debian 11 and they work successfully giving me a root
shell prompt.

I don't think calling this "privilege escalation" or "attack" is correct.
The premise of the post is "the user should not be a root/admin user but
has been assigned sudo permissions to run the package manager" and one
doesn't really need a long article to prove that it's not secure.

I think the article is interesting nonetheless. Some people may think
that granting sudo on apt is OK. In the past, I think "apt install
./something.deb" was not possible.


Random thought: could it be possible to restrict non-sudo users to 
installing packages from repos that are signed by a GPG key that is 
already trusted by the system (the Debian archive key)? That way this 
attack could not be carried out. Then add a Unix group that allows apt 
installation from trusted repos, make apt setuid so it can do the 
privileged operations, and have it check that the user is root or part 
of the non-privileged group.


Just my $0.02.

Kyle

Accepted pre-commit 2.14.0-1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 14:03:34 +0200
Source: pre-commit
Architecture: source
Version: 2.14.0-1
Distribution: experimental
Urgency: medium
Maintainer: Daniel Baumann 
Changed-By: Daniel Baumann 
Changes:
 pre-commit (2.14.0-1) experimental; urgency=medium
 .
   * Uploading to experimental.
   * Merging upstream version 2.14.0.
Checksums-Sha1:
 362ef0529d78ea6b1b4bb4e42a5b667adf9e0df4 1978 pre-commit_2.14.0-1.dsc
 74fda151ff8ecbc19f2c5b62c2a5ed1e3d4d0dd1 218808 pre-commit_2.14.0.orig.tar.xz
 9afa89c29e78c1fec32b193d52458e9d56f489ad 2240 pre-commit_2.14.0-1.debian.tar.xz
 e5ad93f57de2ff0d42d02d1aefa0bce2debb0455 6255 
pre-commit_2.14.0-1_amd64.buildinfo
Checksums-Sha256:
 b69026cfc6d740e410adab5afac51784193e2177cf9c67fb7ecad30f593c5ed7 1978 
pre-commit_2.14.0-1.dsc
 aa628d6955c60a26c978b187e14e6980689a42b399626451091dd1933594e4da 218808 
pre-commit_2.14.0.orig.tar.xz
 8beba2e0b8eea5337a4707cfec1b443445e44f24b6fa2020a8364575b485e759 2240 
pre-commit_2.14.0-1.debian.tar.xz
 69882829d9532a8a7d12f503358296984bdb11fe6feba21b8095fc2e3a955078 6255 
pre-commit_2.14.0-1_amd64.buildinfo
Files:
 e2bba8a2d36da7c4e9b6e51e80eca59a 1978 utils optional pre-commit_2.14.0-1.dsc
 5a5a63441ef21b618f549cd369b913fe 218808 utils optional 
pre-commit_2.14.0.orig.tar.xz
 146165344a577ca5e16b607f0b64dcea 2240 utils optional 
pre-commit_2.14.0-1.debian.tar.xz
 1134d269ebd5e5075b1a0133f0fc3c32 6255 utils optional 
pre-commit_2.14.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmEVDmUACgkQVc8b+Yar
ucczPRAA1h7Wbk7qsmQAV51bmXuTj3jIRHwTY/V0MW1dW4sPw4u4UAFllWP30Y53
V771NtHB8mPYnyy4I9CfVVXGd5dejrwTMnBUvO3G/mUYtjnVKAmiaUA7lnyaOxxo
M0zBRq8TIrXfRlx45g1OJRJ44w02ROz1TF9PcHBYxpkgPDiW5EWs5ut9kaTF+iz5
cQ9ujfxAQJ5KZbzg5/XhC/TLmMwiMpJ6ZK5wYS3uBQvGTxvDcBHO+cRfVN/YHylS
oNzWKG7WTq0YUyQS2R563Ka8aZUdifAESzvuNh2fyouBTrqiq1sMQ66TZx/3g0tZ
4OKtqPFJPQPMBmix2pbkUla6RN7d6dzkb2Lk6tyaVAF45B7sV36daxcv8BACa6j8
F1JGM5cop75UxTbvftTBdyIMiDyQUgRz7pQGjM046bxf1NFPn+dIR/brkFCBSpPC
9dVz8YjWsCNZZUyXmNQLBbqend+cy/R+ocmXRNFzTKa9fJzvswm+6kHpkSfBIT6y
vnHg4MtHetxljF+Lx5LBBXkb21SOP+f4w9H5Ap6FAAodylczSE3aADzd/k2Vf3e4
PsFEOpotIFf/kMtrozTvufs9JufU3N2aZ6fSxUhebUy9zM9oJ9T8oInrh4XjDOPl
uBZJku7vBqYxESO75WOO3uDgvyq70SHAJjA9q/RRTsVI32nibDQ=
=/tB3
-END PGP SIGNATURE-

Accepted identify 2.2.13-1 (source) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 13:58:10 +0200
Source: identify
Architecture: source
Version: 2.2.13-1
Distribution: experimental
Urgency: medium
Maintainer: Daniel Baumann 
Changed-By: Daniel Baumann 
Changes:
 identify (2.2.13-1) experimental; urgency=medium
 .
   * Uploading to experimental.
   * Merging upstream version 2.2.13.
Checksums-Sha1:
 fb76d90852a7daf9345703bdf5657cb69b38c755 1996 identify_2.2.13-1.dsc
 eaef886155875c43675a6e1de38b6d9217af47c4 67520 identify_2.2.13.orig.tar.xz
 4978ade7aad79c38c000787bcdbd5f6b0a3c15db 2364 identify_2.2.13-1.debian.tar.xz
 c1636f3c76c3d6cce2908940b75f34bd5b59c6d1 6327 identify_2.2.13-1_amd64.buildinfo
Checksums-Sha256:
 bd66759ba6f5da35712a183afb9b3f7b4f1a79591df3c44e3c65e63ce976d3ff 1996 
identify_2.2.13-1.dsc
 a1aa9da5c29b03a4cbb87c78d64c529d9fcba1ddac5bd31c235ffa006e7eb552 67520 
identify_2.2.13.orig.tar.xz
 6fae33dd3d70761da49d797d7d1b87b0e3c15f1294202d0b3ee433d8024ee617 2364 
identify_2.2.13-1.debian.tar.xz
 85b115dfdde695ad3c192b7ac8ac5b0f3762aca4094e625b2528e1901812fe8b 6327 
identify_2.2.13-1_amd64.buildinfo
Files:
 32febee3abd73be61ec7e294f8cee602 1996 python optional identify_2.2.13-1.dsc
 30ef99cb24b0ce0b3793ce7e542cbe62 67520 python optional 
identify_2.2.13.orig.tar.xz
 78ab2257f80b87565d265ace1e1bbaef 2364 python optional 
identify_2.2.13-1.debian.tar.xz
 c8dbad4c9f586ac24b02aaf5582686cf 6327 python optional 
identify_2.2.13-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmEVDUQACgkQVc8b+Yar
uccMhhAAkPf3k+oiflXU+SKm7h51vQzeHZzINY5L2VtpY/5RiYucfZipsGe3Mbq8
K7mt7eLtZrDpOzVfxufNgJRZSCu4tP/NMLtsk4vdeXqYjthYBmE3N3vNhzrYWg93
SFzXssi2LCB0j2lZidkyfC2uf4iIkzPsyGmKjSl3MVAH7xnQq5ClSDXu3n9rV2kN
xqJU6wiqAinLALzk9jBZjDTEWkLg9F0OIlyEugxj/olyMn+PcP5mIfZWgldpSfCn
hOKBq4JY4iE18upuMg8eHVHJND9Hn/OY+54U6pmSsy/LDX1tfsisSqSL72pFvLej
ULZ69GhJBGE8ag0v5EApJDgpJSktpGKMXRAJTtPCGH4tCEspip+BQ8P8KcbwE01D
2GcKIALBhYFSFdnk3FxOq3yq4LbfPuEw/v9HTLHjC0XgZpZY9yeYsUkJRie4Dqgx
ZhSGxv24EzlO+HEc8kN+CEtDHBxY8czM2W0JKRmVG8XNFPKGzInhymHktcQmX0u1
tBqKb9df9I0jTHzulxmmXqYtblXAwfvFa4tg3Zy4dmt5dLBmawq51yrKBygFwSof
SV5dAayxD3/YfjDECxVuoOB1e7XJ+AK5pm0HesTd41SAHhXpy2jJDxa/JQqTa0aL
s5iiMjnaaJWsdgFSBlK5j6Ffwib+tpHyuLqb+XRlwTj8T5uUNOs=
=QLyy
-END PGP SIGNATURE-

Accepted dnsperf 2.7.0-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 11:19:24 +0200
Source: dnsperf
Architecture: source
Version: 2.7.0-1
Distribution: sid
Urgency: medium
Maintainer: Daniel Baumann 
Changed-By: Daniel Baumann 
Changes:
 dnsperf (2.7.0-1) sid; urgency=medium
 .
   * Uploading to sid.
   * Merging upstream version 2.7.0.
   * Adding newly required nghttp2 to build-depends.
Checksums-Sha1:
 a8299d3f67b2aa54b1552aad32940a824bfe3543 1964 dnsperf_2.7.0-1.dsc
 d11d6ba369a9a1f5fc55af85729bdf8184769caa 299276 dnsperf_2.7.0.orig.tar.xz
 e7d563ef4ba33d620be2a7f8cc0e889c72d22f8a 2276 dnsperf_2.7.0-1.debian.tar.xz
 064c3b7cd6af87cff8a6fa507c87df3e02fb84ed 6133 dnsperf_2.7.0-1_amd64.buildinfo
Checksums-Sha256:
 6bc556ee34712fa11b8b4458897a7c70f1dee3f66bdfee90340a66baad7c5f11 1964 
dnsperf_2.7.0-1.dsc
 12ae49c803223ec38d8d2796656e9754c4aa6ed18a9af3a3128ef5aa1d9f2c9b 299276 
dnsperf_2.7.0.orig.tar.xz
 20646b632940ac828ab9f263aaa56c76e8a480cecc3613a5583af67c213cb3b4 2276 
dnsperf_2.7.0-1.debian.tar.xz
 d933bee5181370337df7d9312e2356f533b94514539e509f8c2d82698e03307d 6133 
dnsperf_2.7.0-1_amd64.buildinfo
Files:
 a21a91bf85b36953d972665ab859f769 1964 utils optional dnsperf_2.7.0-1.dsc
 21521f8200a3f5794e66519666c1f10c 299276 utils optional 
dnsperf_2.7.0.orig.tar.xz
 2b3e5fb78032e90507c92b6b0cd66edf 2276 utils optional 
dnsperf_2.7.0-1.debian.tar.xz
 cc74c29c5fdc7f89cc31447d2daecb43 6133 utils optional 
dnsperf_2.7.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmEVDBwACgkQVc8b+Yar
ucezhw/9ERjpgrQolcec6U9p5gSQY8ErAEY82Kqkp/gi5buHmJrG2rX0c7sAEHP5
lUisNMYz6OjzQ2iZSMasplHqIs33eoduPmrmuHP7D9XEyPcICY7Jc8WiKpYPPLqc
VmLCCLb49QO4jw0mckMYkmDEsE4EBcHal/iFzHLphQkSnLC0JZpqfUR5rmPQeLHE
VDsg/eW2TkoBRhyiNMjJUnwW7drPKNoOMLxMptbTkYEdqy9ccl3C5IEmFbfDoN6Q
Lj3mJA2bhzxEZ1kcP9p1h97aMQX8iSlAt/OeT69zXKAeH0K3Z8ToQHdm7G7yMr+y
+fMCXpJnHouYZOkt6I4OPNGHgdxabv4qR3OEnxRXz1GEnlhTmLFnR41EzkgIGBQ1
rSmc7P5yubblCelDLQsZZLEI1cqTwhI/D5AuYixv3+JqAF/E09j1wbEHXKpBuFLO
qurohhN1ouoh2bIX71jV10AbyKnRldlNWp2YNqVq2WoSfNOwh0W/HY+SyMwBlO+H
iSVH2IfydfKKyCGfP80rxZDLXGgu6t6vfE0j1sswimKsu1HDVWybQYv+wZFOI4RY
2RBCAOqmdemUIWxKKyquPrf/WhQfiynw78JCQGEHXM1hpk2NFQFC04FyZHQVtUUL
EB7s2+KFq9b5o26K5tLCvedBeR2hQD61ux9uiGIakf9zw94KAOY=
=aJZQ
-END PGP SIGNATURE-

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le jeudi 12 août 2021, 10:16:45 UTC Bastien Roucariès a écrit :
> Le jeudi 12 août 2021, 09:52:53 UTC Bastien Roucariès a écrit :
> > Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> > > On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> > > >Bastien Roucariès wrote:
> > > >> I am going to compile shell.efi from source.
> > > >> 
> > > >> I whish to install to something stable, but I need an arch triplet in
> > > >> order to put in a multiarch (like) location.
> > > >> 
> > > >> I suppose that it will be  x86_64-efi-none (or maybe
> > > >> x86_64-windows-efi
> > > >> )  and i686-uefi-none ?
> > > 
> > > As Simon says, *definitely* not *windows* here please! :-)
> > > 
> > > >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> > > >GRUB-specific target.
> > > >
> > > >UEFI is effectively an "operating system", insofar as it provides a
> > > >runtime environment with some baseline properties and a set of system
> > > >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > > >since there is an OS of sorts.
> > > >
> > > >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > > >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > > >right names for these targets in other toolchains, as well.
> > > 
> > > Nod, agreed. I think that makes sense.
> > 
> > Ok thanks
> > 
> > For the triplet this will be :
> > -  i686-unknown-uefi
> > - x86_64-unknown-uefi
> > Where should I push this triplet ?
> > 
> > Ant therefore we get the multiarch tupple:
> > - i386-uefi
> > - amd64-uefi
> > If I am right ?
> > I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I
> > should open a bug somewhere (dpkg ?)
> 
> I have changed the arch name, it will be:
> uefi-i686
> uefi-amd64
> with multiarch tupple i686-uefi, x86_64-uefi
> 
> I think it is better in line with current kfreebsd pratice...
Changed a new once after implementing debian arch-name to uefi-i386 will allow 
to use uefi-$(DEBARCH) in makefile
> 
> Bastien
> 
> > Bastien
> > 
> > Bastien



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

Accepted apache2 2.4.48-4 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 12 Aug 2021 11:37:43 +0200
Source: apache2
Architecture: source
Version: 2.4.48-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Apache Maintainers 
Changed-By: Yadd 
Changes:
 apache2 (2.4.48-4) unstable; urgency=medium
 .
   * Fix mod_proxy HTTP2 request line injection (Closes: CVE-2021-33193)
Checksums-Sha1: 
 bfc9f0ac5ed31590c49d4808fae640b9ef1337d5 3507 apache2_2.4.48-4.dsc
 bb0ce71c42ba322d2640729aab06c86ac90bfe0e 891632 apache2_2.4.48-4.debian.tar.xz
Checksums-Sha256: 
 1fdcf4efafa2ea73c280c9971e0bd171bc8c9cc37ffb0889a7a15a0fbc45f126 3507 
apache2_2.4.48-4.dsc
 ef3177be27fdc2dc1901a7d5e1151f2f825a9a69f9447b89682e95d4910c8bec 891632 
apache2_2.4.48-4.debian.tar.xz
Files: 
 ac06fdc51d138017a6f2e2f0a576294a 3507 httpd optional apache2_2.4.48-4.dsc
 93bc35ba7ed7fce2a24099bf5b4a6e0f 891632 httpd optional 
apache2_2.4.48-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmEVCvoACgkQ9tdMp8mZ
7unsgg/+JgwD1F5ejINyfmqCCZnhvdxzGnaKTrfu4YcazvMqiYky23LdRbH2pRZl
8d634XM11WlsWpWq6d01dcR+bTgiqLZO9CvE6NDVaJPureTXMUplsgkuBcJCYRL3
5tB5fUq5g27FBJZGa3YVPD94lGkLRHlO07zZnaWsyO4KHHsTKKxVVTdlG3YpwqMV
HeIUnh+AulGs4cfv0gJQwErZbmnFYGz/caE2BqT+UVqSXkiXdSD9PUIfYE8RtVR4
Yc4PxEWIsarXljp8ItqlGTit9kBGSM5Fa6LS1SfOE1PdQNS7/ONlk9hg2UVt3oIn
dlOJAZ88VS4aMYOAM5OD2e7Dmexi8XaGpkAYPiMe9/0LJrtU9kAh2cbTGC01TNoh
wp7azDjbbSC5YJjqoj11ZCR0OGPEqdKhfUqqDE2i9ybjoWO3Xsx1r/+NvQUpiue9
I8Bc4OdLm+7M7U9sJofLusMzNFcLvwOamLq8hhI7yFpM1CKJXWDEMdwugYCxuvav
zbCun5T7FTYlFRdumASIROyix9MmDDRI39T1foQRgiIvnlxJOm3fVdHtfzOqB76p
wlLZtjWCObqGANAO8a1cm1MBVsjBCHcdYZV4PFp7fJSj1ClO66ko7gf52OA0Ba2H
Npd2b/CKj2BZtHD8Ud3HWYPMFDuZHT2qf4RfZUlvvZlyZL84VM8=
=0fzl
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[David Kalnischkies]

On Thu, Aug 12, 2021 at 08:32:14AM +0200, Vincent Bernat wrote:
>  ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:
> >> I just ran across this article
> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> >> the attacks on Debian 11 and they work successfully giving me a root
> >> shell prompt.
> > I don't think calling this "privilege escalation" or "attack" is correct.
> > The premise of the post is "the user should not be a root/admin user but
> > has been assigned sudo permissions to run the package manager" and one
> > doesn't really need a long article to prove that it's not secure.
> 
> I think the article is interesting nonetheless. Some people may think
> that granting sudo on apt is OK. In the past, I think "apt install
> ./something.deb" was not possible.

It wasn't that easy, but if you can feed config options into apt you can
basically do whatever (like setting a sources.list, including your own
local repo including your bad deb). Beside the command line -o and -c
you can also use environment variable APT_CONFIG.

APT (, dpkg, …) just never was designed to be used in a restricted way or
we wouldn't have hundreds upon hundreds of options to do all sorts of
(sometimes) crazy things like using apt for bootstrap…

I would say dd-schroot-cmd is a good example of what you would need,
although I am relatively sure someone truly hostile can find a way if
enough energy is invested (and then there is always the risk of the APT
team adding yet another innocent option derailing the plan like the
ability to install deb files directly used to back in 2014).


> Maybe it would be worth to also set LESSSECURE (less is not the default
> pager on minimal installs but I think it is the most common, more cannot
> be secured this way).

External solvers (--solver/--planner) are run as a (configurable)
different user, currently defaulting to _apt. That is nice, as it isn't
root, but _apt is also used by the download methods, which means it can
have permissions to files it shouldn't have. Ideally, we would need
an extra user for that. Except that different solvers probably shouldn't
be able to access each other, so multiple I guess. Can't really be nobody
(or a temporary) as the solvers might very well have their own config,
cache, I could even envision some asking an online oracle for input
(reproducible, open bugs, …) and firewall rules for nobody are bad ………
sorry, my head hurts, were where I?

Right, pagers. Ideally I would like to not run them as root as well,
but they are a lot more user facing, so if your usual config (hello
lesspipe) disappears it is sad. Fun would be to run the pager as the
user who sudoed initially… :P


We could set this environment variable I guess, but dpkg doesn't set it
either and a quick codesearch in Debian suggests that while the variable
seems sufficiently ancient (console-log changelog mentions it in 2000)
I don't see a whole lot of adoption – and golang-github-sean--pager
surprises me with setting it only if the called pager is named less.
Not sure I like systemds envvar to override an envvar either
(and they of course all use different LESS flags to begin with).

So, before I am rushing off to do whatever I like, could we perhaps
agree on a "sensible-restricted-pager" (I dare not to name it secure…)
sort-of implementation first?


Oh and, btw, there is no point¹ in running 'apt changelog' with root
permissions – it is beside the point here, but I feel obligated to
mention it.


Best regards

David Kalnischkies

¹ well, there is a teeny weeny one: an outdated binary cache is updated
and stored on disk rather then build in memory and discarded afterwards,
but ideally your cache isn't outdated – it usually isn't if you aren't
doing things with envvars, options, …


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Philipp Kern]

On 2021-08-12 12:23, Polyna-Maude Racicot-Summerside wrote:

Now if people start doing stuff they don't master than it's not
privilege escalation but much more something like another manifestation
of human stupidity. And this, there won't be a number of article
sufficient to make people change.

[...]

This is only a article made to get people onto a website and see
publicity or whatever goal the author set. There's nothing genuine in 
there.


I think it's less about human stupidity than about all the knowledge you 
need to acquire (and retain) to securely administer a system. It is not 
easy. The concern expressed here is pretty much common knowledge among 
sysadmins of ye olde times. Of course you can abuse this, and yes it got 
easier recently. The boundary that sudo provides is very blurry, hard to 
understand and full of footguns. People need to come up with better 
boundaries - or in this case they might already exist. Basically you 
need to be able to validate the request and execute it in a secure 
environment. At basically every shared environment people come up with 
some way to allow package installation, but it's not easy to find the 
right instructions on how to do this properly on Debian[1]. I'm not 
aware of a well-trotten path for maintaining a system where users do not 
need root. Throw in some reluctance to deal with "newfangled things" (to 
establish new, maybe controversial boundaries) and you end up with every 
one fighting for themselves.


Now of course there's value in people having this knowledge and 
companies should recognize this value. But from communication and 
awareness we learn, no?


Kind regards
Philipp Kern

[1] E.g. thinking of https://debian-handbook.info/browse/stable/

Accepted pmix 4.1.0-1 (source amd64) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 12 Aug 2021 10:24:33 +0100
Source: pmix
Binary: libpmix-bin libpmix-bin-dbgsym libpmix-dev libpmix2 libpmix2-dbgsym 
python3-pmix python3-pmix-dbgsym
Architecture: source amd64
Version: 4.1.0-1
Distribution: experimental
Urgency: medium
Maintainer: Alastair McKinstry 
Changed-By: Alastair McKinstry 
Description:
 libpmix-bin - Process Management Interface (Exascale) library - tools
 libpmix-dev - Development files for the PMI Exascale library
 libpmix2   - Process Management Interface (Exascale) library
 python3-pmix - Process Management Interface (Exascale) library - Python wrapper
Closes: 990253
Changes:
 pmix (4.1.0-1) experimental; urgency=medium
 .
   * New upstream release
   * Include reproducibility patch from Vagrant Cascadian. Closes: #990253
   * Add libevent-dev, libhwloc-dev and zlib1g-dev to libpmix-dev's Depends
Checksums-Sha1:
 f94a9197382a01d91ed06e923c4782937e3182f0 2231 pmix_4.1.0-1.dsc
 53f95d544a6b43d035965f432f136fa828e8281d 1171216 pmix_4.1.0.orig.tar.xz
 477c8d3885e57110bc4e8c4070d48be656b169ec 9072 pmix_4.1.0-1.debian.tar.xz
 84d0b57c89851cb19574587094bb783d67841a41 143592 
libpmix-bin-dbgsym_4.1.0-1_amd64.deb
 8644efeeb51055c7e4f7f857564a91a4f3fc6889 39736 libpmix-bin_4.1.0-1_amd64.deb
 458206db8d564402fd6fa94e6e5dcf7b4e3d74b7 711664 libpmix-dev_4.1.0-1_amd64.deb
 e274500583e4c5770e1daeb84b8ea52576003eab 2385104 
libpmix2-dbgsym_4.1.0-1_amd64.deb
 fa58949512f43e3a7afaaad4c3a6536917ae1f1c 567828 libpmix2_4.1.0-1_amd64.deb
 621a0153d61880e9db1fd55ae35393c77cca01a0 10260 pmix_4.1.0-1_amd64.buildinfo
 0b312152de7781eed90581c8f4c34fd72d5fcfa0 1280164 
python3-pmix-dbgsym_4.1.0-1_amd64.deb
 1d382d109aa272adc24bd12194dc967debd26b8e 277812 python3-pmix_4.1.0-1_amd64.deb
Checksums-Sha256:
 9842788b12c44b4a89595f98ea4cdf715136e63fc1e5a353da439e58cd8e4ce1 2231 
pmix_4.1.0-1.dsc
 0f57fedb377e84e34c2af3f6e6e0e4289fcb98755187f740b673dba4f7709f7d 1171216 
pmix_4.1.0.orig.tar.xz
 edf813a2c87d50b236d05a98e1a47a5312aa4712390e40edabb902e4c0f918c6 9072 
pmix_4.1.0-1.debian.tar.xz
 6e0a19df93ecc4fe0446b90a5abf9be0b58fbd6afdb42ab3c4f8b3e954f66323 143592 
libpmix-bin-dbgsym_4.1.0-1_amd64.deb
 92709cdd22d78ecda7de98dd0f90e813e7816c592998ba56cabe5227b7fb2b4c 39736 
libpmix-bin_4.1.0-1_amd64.deb
 4edae5b5e224ecbb0fe1d40d2db758a0864bf370796190798dd6fb66fdfc7587 711664 
libpmix-dev_4.1.0-1_amd64.deb
 2e9805794d1708d2d885c2aa99e27497c38b9e3c45e44848fc6c5d1f5ee489f5 2385104 
libpmix2-dbgsym_4.1.0-1_amd64.deb
 dc52781c9120577f7fc24dd69bcfd41ec3793f26ef076571bf69ca5a11e45f01 567828 
libpmix2_4.1.0-1_amd64.deb
 bfd5c73b0b7872812fb1ac52245c4c34b73f4661e1c1efc434f63f8badc79af7 10260 
pmix_4.1.0-1_amd64.buildinfo
 498c96067d9933e41c265513165b0cc7c5b22396e32da57e7e4bdf2ecf70d11c 1280164 
python3-pmix-dbgsym_4.1.0-1_amd64.deb
 e5ddee616603c948884cf2aaa44a5a9dd9cf773a3bd8c2380ee7e2cc56f58d8f 277812 
python3-pmix_4.1.0-1_amd64.deb
Files:
 fd0309f5de848ae496255c09b43d2249 2231 net optional pmix_4.1.0-1.dsc
 445a0ce37ab19deb5d2b00f9df177761 1171216 net optional pmix_4.1.0.orig.tar.xz
 c95b6520d8d2ecec986cd2e465fcac17 9072 net optional pmix_4.1.0-1.debian.tar.xz
 8534620b79fddaf328f03f655662015d 143592 debug optional 
libpmix-bin-dbgsym_4.1.0-1_amd64.deb
 a6b54f187e5e8497a664e0ab8a1bf92d 39736 net optional 
libpmix-bin_4.1.0-1_amd64.deb
 9132cca2c45a149f5bf0e5e583addd3c 711664 libdevel optional 
libpmix-dev_4.1.0-1_amd64.deb
 38a429b9494f662c2c5ac215426be4b5 2385104 debug optional 
libpmix2-dbgsym_4.1.0-1_amd64.deb
 575a6fdfb1289ee05fc13007797556f4 567828 libs optional 
libpmix2_4.1.0-1_amd64.deb
 04b1f94d4822688470eace1f58484ab7 10260 net optional 
pmix_4.1.0-1_amd64.buildinfo
 80be0501f11c445a0066a442380eac39 1280164 debug optional 
python3-pmix-dbgsym_4.1.0-1_amd64.deb
 e5f4d05cb51e7f21d6139c2515544aea 277812 net optional 
python3-pmix_4.1.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmEU+VkACgkQy+a7Tl2a
06WyBw/7B4xiK6cgI+Uzod72dcamnWIq88gt+sxr443UmWOJiaV97AnhBzaC5eTO
J/JgO5R66VSQfKVY31asy+L6ZP2cfBDfYZanHFPvglN0ukBb+o7RPk79KScaByOl
DlOys7I+v0sFJVswt+Zkh6sR/xf46dJ45mKC0uj05Q+qp+2LVdHWbb98MVD7ZM2+
JJ15ZkJwRN0nM5qTRmwyiIVl5cTiPzYeS3FMFC+9vbHuTH9WsEO6SEhGvXn0yu5s
7mEvs1Fw+BNwE2GmoyvtWCIt3mu4E00eEhyQ93JA/yAOnDIXWZZeJ8RthzeYZw7Y
x+xmh2+IVfSuuAumV3zUtrkHgmDzXpI+Puz/+DerLGz+swwX9qIn5M1K2Ult71w6
hmwrIlLWsbSZf7fjB1dY235XTRfSconeVDJb2AcwdZ02f61Xrxe58KzE1eRQNDRG
nHsJFHLwOmPD9QF6KdqOMbl1ykrKFomoBi5R0/uLYLDYXZXuCvg2cSEzWRwndAZW
a+osp0phQAqf5Bu7WsCZm8JeG7asN7GL3FcAR/uuhg9EnY+Spas+aJV7AjAG+zan
Y2gghYv8OfCOX0QvLe3idaehDMq0tul+MTHRvroMe6WH/8YvzzrpTa9TU0oh/CY2
HOvswbxRjr/35eVfGXVR5q1sJsQ15U5PPLQ1GginLsbL/SRXdbE=
=NW3E
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-08-12 2:25 a.m., Brian Thompson wrote:
> On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote:
>> On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
>>> Would you agree that there is an issue with sudo access that is
>>> enabled
>>> by default on most Debian and Debian-based distributions? The bug
>>> may
>>> not be in apt, but it definitely lives somewhere.
>> Do you think "sudo access" itself is a "privilege escalation attack"?
> 
> I do not. I think that the possibility of dangerously configured sudo
> access is a vulnerability.
>
So this is not a *privilege escalation attack* but more a warning to all
user that "using sudo can be used to do stuff as root" ?

We are so lucky that someone wrote a article on the subject and you
shared it with us.

But this is not a privilege escalation attack, it's something that is
planned and known.

1. Read apt documentation, it is said that script will be executed as root.
2. Read sudo documentation, it is said that allowing user access to some
program as root should be as limited as possible.
3. Read sudo documentation, the goal is allowing to run a root.

Now if people start doing stuff they don't master than it's not
privilege escalation but much more something like another manifestation
of human stupidity. And this, there won't be a number of article
sufficient to make people change.

If I'd have apt access under sudo and would like root access, this would
be the last method I'd use. There's so many more, starting by modifying
a existing package and adding a backdoor to it, the updating the system.
Adding SSH keys, adding a line to sudoers, etc.

This is only a article made to get people onto a website and see
publicity or whatever goal the author set. There's nothing genuine in there.

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le jeudi 12 août 2021, 09:52:53 UTC Bastien Roucariès a écrit :
> Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> > On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> > >Bastien Roucariès wrote:
> > >> I am going to compile shell.efi from source.
> > >> 
> > >> I whish to install to something stable, but I need an arch triplet in
> > >> order to put in a multiarch (like) location.
> > >> 
> > >> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi
> > >> )  and i686-uefi-none ?
> > 
> > As Simon says, *definitely* not *windows* here please! :-)
> > 
> > >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> > >GRUB-specific target.
> > >
> > >UEFI is effectively an "operating system", insofar as it provides a
> > >runtime environment with some baseline properties and a set of system
> > >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > >since there is an OS of sorts.
> > >
> > >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > >right names for these targets in other toolchains, as well.
> > 
> > Nod, agreed. I think that makes sense.
> 
> Ok thanks
> 
> For the triplet this will be :
> -  i686-unknown-uefi
> - x86_64-unknown-uefi
> Where should I push this triplet ?
> 
> Ant therefore we get the multiarch tupple:
> - i386-uefi
> - amd64-uefi
> If I am right ?
> I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I
> should open a bug somewhere (dpkg ?)
I have changed the arch name, it will be:
uefi-i686
uefi-amd64
with multiarch tupple i686-uefi, x86_64-uefi

I think it is better in line with current kfreebsd pratice...

Bastien

> 
> Bastien
> 
> Bastien



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

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> >Bastien Roucariès wrote:
> >> I am going to compile shell.efi from source.
> >> 
> >> I whish to install to something stable, but I need an arch triplet in
> >> order to put in a multiarch (like) location.
> >> 
> >> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi 
> >> )  and i686-uefi-none ?
> 
> As Simon says, *definitely* not *windows* here please! :-)
> 
> >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> >GRUB-specific target.
> >
> >UEFI is effectively an "operating system", insofar as it provides a
> >runtime environment with some baseline properties and a set of system
> >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> >since there is an OS of sorts.
> >
> >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> >right names for these targets in other toolchains, as well.
> 
> Nod, agreed. I think that makes sense.
Ok thanks

For the triplet this will be :
-  i686-unknown-uefi
- x86_64-unknown-uefi
Where should I push this triplet ?

Ant therefore we get the multiarch tupple:
- i386-uefi
- amd64-uefi
If I am right ?
I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I 
should open a bug somewhere (dpkg ?)

Bastien

Bastien


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

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Pirate Praveen]

2021, ഓഗസ്റ്റ് 12 8:51:55 AM IST, Timothy M Butterworth 
ൽ എഴുതി
>I am fine with Debian's release cycle but It would be nice to see more
>packages. For example Debian is missing KDE's Amarok music manager. I
>am happy to see Debian 11 gained KDE Elisa music manager. I am sad to
>see that VirtualBox is not available on Debian 11. I had to jerry-rig
>it using the Ubuntu Focal repo from Oracle.
>

We have https://fasttrack.debian.net and currently gitlab, matrix synapse and 
virtual box is available there in buster-fasttrack suite (though only gitlab is 
available via bullseye-fastrack now, I hope other two will come soon). Packages 
that don't fit in regular backports can be shipped via Fast Track.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Debian package manager privilege escalation attack

[Philipp Kern]

On 2021-08-12 08:32, Vincent Bernat wrote:

❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:


I just ran across this article
https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I 
tested

the attacks on Debian 11 and they work successfully giving me a root
shell prompt.
I don't think calling this "privilege escalation" or "attack" is 
correct.
The premise of the post is "the user should not be a root/admin user 
but

has been assigned sudo permissions to run the package manager" and one
doesn't really need a long article to prove that it's not secure.


I think the article is interesting nonetheless. Some people may think
that granting sudo on apt is OK. In the past, I think "apt install
./something.deb" was not possible.


I think the actual solution here is PackageKit. My understanding is that 
it does not let you do this when you grant the package-install 
permission to users. And it even lets you do flexible policies through 
polkit.


And sure, that still allows users to install packages from any 
configured source which might include packages with vulnerabilities or 
intended privilege escalation. But that feels like a different, more 
general problem.


Kind regards
Philipp Kern

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 10:31 +02, Ansgar:

>> I give myself password less sudo to "apt update" (without additional
>> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
>> thinking this should be safe, but now I need to check if the pager is
>> properly restricted when displaying NEWS file.
>
> These are not safe to be run under `sudo` without giving the invoking
> user full access. As a random example: dpkg's conffile prompt offers to
> open a shell.

Ack. I'll avoid this from now on.
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#992124: ITP: puppet-module-mistral -- Puppet module for OpenStack Mistral

[Thomas Goirand]

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

* Package name: puppet-module-mistral
  Version : 18.4.0
  Upstream Author : OpenStack Discuss 
* URL : https://opendev.org/openstack/puppet-mistral
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for OpenStack Mistral

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 Mistral.

Re: Debian package manager privilege escalation attack

[Ansgar]

On Thu, 2021-08-12 at 08:32 +0200, Vincent Bernat wrote:
> I give myself password less sudo to "apt update" (without additional
> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
> thinking this should be safe, but now I need to check if the pager is
> properly restricted when displaying NEWS file.

These are not safe to be run under `sudo` without giving the invoking
user full access. As a random example: dpkg's conffile prompt offers to
open a shell.

For the same reason "apt install [package-name]" is unsafe as well even
when you ensure that "[package-name]" only contains characters from the
set [a-z0-9A-Z-] and does not start with a "-".

As another example, being able to answer debconf prompts from certain
packages is likely also root-equivalent.

If you want unprivileged users to manage (install, remove, update)
packages, then I believe PackageKit[1] tries to offer this.

Ansgar

  [1]: https://www.freedesktop.org/software/PackageKit/

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 11:38 +05, Andrey Rahmatullin:

>> >> I just ran across this article
>> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> >> the attacks on Debian 11 and they work successfully giving me a root
>> >> shell prompt.
>> > I don't think calling this "privilege escalation" or "attack" is correct.
>> > The premise of the post is "the user should not be a root/admin user but
>> > has been assigned sudo permissions to run the package manager" and one
>> > doesn't really need a long article to prove that it's not secure.
>> 
>> I think the article is interesting nonetheless. Some people may think
>> that granting sudo on apt is OK. 
> Some people may think granting sudo to vim is OK, but we need to educate
> in general that some programs can run other programs, and so restricted
> sudo is not as restricted as it sounds.

That's the point of the article, isn't it? Your example is how I got
fast-forwarded admin when I was at school/uni. So, it's unlikely to
change.
-- 
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
-- Mark Twain, "Pudd'nhead Wilson's Calendar

Re: Debian package manager privilege escalation attack

[Andrey Rahmatullin]

On Thu, Aug 12, 2021 at 01:25:06AM -0500, Brian Thompson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote:
> > On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> > > Would you agree that there is an issue with sudo access that is
> > > enabled
> > > by default on most Debian and Debian-based distributions? The bug
> > > may
> > > not be in apt, but it definitely lives somewhere.
> > Do you think "sudo access" itself is a "privilege escalation attack"?
> 
> I do not. I think that the possibility of dangerously configured sudo
> access is a vulnerability.
Yet you are talking about "sudo access that is enabled by default".

Or are you saying sudo access to apt is enabled by default on most Debian
and Debian-based distributions?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Andrey Rahmatullin]

On Thu, Aug 12, 2021 at 08:32:14AM +0200, Vincent Bernat wrote:
> >> I just ran across this article
> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> >> the attacks on Debian 11 and they work successfully giving me a root
> >> shell prompt.
> > I don't think calling this "privilege escalation" or "attack" is correct.
> > The premise of the post is "the user should not be a root/admin user but
> > has been assigned sudo permissions to run the package manager" and one
> > doesn't really need a long article to prove that it's not secure.
> 
> I think the article is interesting nonetheless. Some people may think
> that granting sudo on apt is OK. 
Some people may think granting sudo to vim is OK, but we need to educate
in general that some programs can run other programs, and so restricted
sudo is not as restricted as it sounds.

> In the past, I think "apt install ./something.deb" was not possible.
Yup, so "and programs you allowed in the past can gain new features even
if they didn't have them in the past".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:

>> I just ran across this article
>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> the attacks on Debian 11 and they work successfully giving me a root
>> shell prompt.
> I don't think calling this "privilege escalation" or "attack" is correct.
> The premise of the post is "the user should not be a root/admin user but
> has been assigned sudo permissions to run the package manager" and one
> doesn't really need a long article to prove that it's not secure.

I think the article is interesting nonetheless. Some people may think
that granting sudo on apt is OK. In the past, I think "apt install
./something.deb" was not possible.

I give myself password less sudo to "apt update" (without additional
options), "apt upgrade" (same), "apt full-upgrade" (same). I was
thinking this should be safe, but now I need to check if the pager is
properly restricted when displaying NEWS file. A similar
"vulnerability" was fixed in systemd:

 - https://gtfobins.github.io/gtfobins/systemctl/
 - 
https://github.com/keszybz/systemd/commit/612ebf6c913dd0e4197c44909cb3157f5c51a2f0

Maybe it would be worth to also set LESSSECURE (less is not the default
pager on minimal installs but I think it is the most common, more cannot
be secured this way).
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Debian package manager privilege escalation attack

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote:
> On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> > Would you agree that there is an issue with sudo access that is
> > enabled
> > by default on most Debian and Debian-based distributions? The bug
> > may
> > not be in apt, but it definitely lives somewhere.
> Do you think "sudo access" itself is a "privilege escalation attack"?

I do not. I think that the possibility of dangerously configured sudo
access is a vulnerability.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvsITHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GffuzD/9+1W9z3AA/DFy5HgBgV5ntSiP6hhQ4
PdybHxQ1zP7A4uZHdGV4IqsfOKWkuhnzV/dA5Rpk7pvT1iWDQgkz7uEK5HXkQT4N
QCg3MeBbqdDpqG5UakVnyu+qGJ26pRyQYmq54dZOUFmNJL8uF5BwnPg7d4NWikds
0e2QrYtyaFFVaInhDHE7uM+eYQtmWSP5yXYxGy9RLjUpLB1SPqAxeR4bZxeJ2yAz
873L1VpWOHbmxsRZj6NRH6dh2o87fqAq1BcnJZrLpbm38YKIE8PKtaNjKlhFLItt
hwnGPJfobrxGG4gPgwJBB2S+FP+K6kWxSSA9y1lpAo+kLZlZFENWWxnGpgBIZ2+Q
DZTFM6nPkwAvWLz1rpP5tf9Kqa7ABLyHnHdNqHAd44VtihCjwFkRtzPQgoysPGux
nghHMpCmdYXuen6xaPaDSvR5emy6XVuuYvEBVjGMtR4VwJsYwgLOv1hbh+yN+fTx
ItpwQjOXsD0PgGPs5BjF2G2aGHiVcHLuAZ6q0JbBo+QsCC5T3cDEJyPyuImRpNUX
zQ9oyA8crGO5kq/7qz1I8/mMBrbaHKtgI9sCwwOwT56EUCvN2J0VcQGgrqQ0mVEB
fJnCJFGlBrixpwbrMOik/P4QtibprVh070MgATb0QunTxyJLvnC3y/1XySkRCY8j
eLvWe2IBKBalmw==
=4yEj
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Andrey Rahmatullin]

On Thu, Aug 12, 2021 at 01:17:03AM -0500, Brian Thompson wrote:
> > > Thank you for bringing this to everyone's attention. This are very
> > > real
> > > vulnerabilities. 
> > How are they vulnerabilities?
> They are vulnerabilities because the user is susceptible to this kind of
> attack by default. 
No. Read the article.

> I don't think a lot of users are security-conscious enough to prevent
> sudo access for commands like apt and snap.
The focus of the article is "sudo access *only* to apt". When we talk
about unrestricted sudo access it doesn't even make sense to talk about
privilege escalation because unrestricted sudo is by design a privilege
escalation.

> > Ah, so you haven't read the article.
> No, I read the article.
Yet you are talking about things out of the scope of the article.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Andrey Rahmatullin]

On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> Would you agree that there is an issue with sudo access that is enabled
> by default on most Debian and Debian-based distributions? The bug may
> not be in apt, but it definitely lives somewhere.
Do you think "sudo access" itself is a "privilege escalation attack"?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian package manager privilege escalation attack

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2021-08-12 at 10:44 +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 11, 2021 at 10:55:44PM -0500, Brian Thompson wrote:
> > Thank you for bringing this to everyone's attention. This are very
> > real
> > vulnerabilities. 
> How are they vulnerabilities?
> 

They are vulnerabilities because the user is susceptible to this kind of
attack by default. I don't think a lot of users are security-conscious
enough to prevent sudo access for commands like apt and snap.

> > NPM has similar issues with stopping malicious packages from being
> > published to the FTP server.
> That's not what is the article about.

Correct, but NPM served as an anecdote for a point I was trying to make.

> Ah, so you haven't read the article.

No, I read the article.

- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvN8THGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfZx5D/4i2kVC+zcYFXYad13SPPJjwIRI0pM3
PMKwdb4NIFG8eG3vurWbq/p7cUihXjahpq1xbTkifzfAnE22y9k7Sj85vDR5j2F/
Pfir09qymjLoOdmFCCRuRdraBe8bUuaWolHnHIVdT0Jif3KeRk/I6njn0ZKa0dI3
2yaA9owJPIxRUGki7OMFLwz5WdoTU4t77AHD3JiU9e1QExV/Z2AQi6twGAVqJVVY
JtUan3P/NmWBsBjPxPg+zuAp3/YVPpHBS02mI3A+sHp2qzQDUQ3S9lpuEx/QuxN0
BhLynoqugG8ZQDJvymENFCvr2WYRz1/0heE/YouR9MCLpchdZidSzyTsgvj6BH9d
WipAdocRzqgEWvL+vDbcnG8JKHhzGqpeny08fbMKbl/Nmm7cS781MdWtw7tmk0Nq
Bs3yzneBihgi9duQrvlIncaroBv5FkoGCzNPvL8dKudA8dVLyPWG0rlPSrkRLSfs
zYSVRL/D99G+f8YCz+HmPq1CYEKNxeATZI/l1qrUZq6K5yAlUWHlmEnylZILcUAm
ZnAgIQnpTq/SrH8QLH/03qSZ/lqYi05Rn/Q0WOkv8g+t5I7mytvzKWu9qsZUopWg
YFmVp/4+eyg1SjaCM5PCO6tv2D8AjK8UW0uzwTXT1LF+2DeM7sC8/hgIU49Ebv/T
Q6ZdTfoS3cbL3g==
=W0yz
-END PGP SIGNATURE-

Re: Debian package manager privilege escalation attack

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2021-08-12 at 07:38 +0200, Niels Thykier wrote:
> Timothy M Butterworth:
> > All,
> > 
> > I just ran across this article
> > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I
> > tested
> > the attacks on Debian 11 and they work successfully giving me a root
> > shell prompt.
> > 
> > Tim
> > 
> 
> Hi Tim,
> 
> All of the attacks presented assumes that the local user has "sudo"
> permissions to run apt and use that as the basis for escalating
> privileges (not commenting on yum or snap).
> 
> I think it is a good demonstration of how some sudo policies are too
> lenient and can be exploited.  Though I am not sure this is a bug in
> apt, as I do not think apt ever promised to be "safe" to use from a
> constrained sudo policy.
> 

Would you agree that there is an issue with sudo access that is enabled
by default on most Debian and Debian-based distributions? The bug may
not be in apt, but it definitely lives somewhere.

> Thanks,
> ~Niels
> 
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUu9UTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfb8QD/sH4ko8qsI7Dxyf4t8oM7bRWnGeyYXG
C+e/7kb8ePKXJcSIspbzlEHefsp/chqjWQnA8f3Kqjdn77eGVecxk5O7cyN0nJyC
Ih3LyLvuU2CoeLsPw7+0g4Ta81sdNh22xl/M1V3Fkbg5E1AWL7dSLwuj7LzgH5Fo
w/YudfGKiyZD7gtdgOP3rfae0rLsgxklUsZQOSEEHyYGuwWZRhwNimWnytKI9XC2
z4LrAxeW07e3GA/RjUWp86/+Lub7RchirCvkV2HpAFRY88mBQbHGLjskyRma3FQ4
rfkuGOQ8R34MHuth7HeSjzuKQhqQ7FRFbH5n0rPB1O20jnjbtO/0UuQ88Foha2Um
+S//kLXXpPEo/52nBGnT9KmRTTaMAmqbZPTuE2F5T2hLtNBhgK8HPEcMpn7jW1vT
EYYg3aoNvO6pFe0jL9gGomViS+JoCcFkXQI4xaPqkQchjOkTaQNym8alxDiZqwEk
rKq8Fz3mTlMYQHpuTM9qNLPCkTWlMg+mFsEarZJcWtjrHiqIKFFPAH+G9SMqHRxD
LUcU0iKcoZtBvtSnDnt8QFhwc9eWPFqitoPihliAkfORC7KMmMJ5QgEd0TN/5r6n
LmyVo7n8zF2D1ZwUAty3WfWMpRgx8TC2keXsuLWyqW9EZO/PSQplO86tjzYDYWfg
WgY5vDsL7eMzFg==
=QmLv
-END PGP SIGNATURE-