Re: debian sid --> lxde

[Simon McVittie]

On Mon, 17 Aug 2020 at 01:44:14 -0300, Tiago Zaniquelli wrote:
> After [configuring unstable apt sources] I executed apt-update and apt
> full-upgrade, so after that show me
> that the "wicd" will removed, but I can't do that because if I do that I
> will lost the program that configure my WiFi.
> 
> So How I do to resolve that?

Either switch to something other than wicd (network-manager is a popular
alternative), or help the maintainers of wicd to fix the release-critical
bugs that prevent it from being installed in unstable (#885140, #938823,
#956159, #947589).

The underlying problem is that wicd was developed against Python 2, GTK 2
and PyGTK, which are no longer maintained (PyGTK was deprecated in early
2011 and was recently removed from Debian).

The upstream bug requesting porting to Python 3, GTK 3 and PyGI is
, but it was opened in late
2011 and does not seem to have had significant activity since then.

smcv

epoch bump for babl and gegl libraries

[Simon McVittie]

The GNOME team intend to add an epoch to the babl and gegl libraries,
so I'm checking for consensus (Debian Policy §5.6.12.1). As usual with
epochs, this is a bad situation that I am trying to mitigate as much as
possible, rather than anything elegant or exemplary.

babl and gegl are 2D image libraries used by GIMP and GNOME Photos.

Historically, versions of these packages were shipped by the third-party
deb-multimedia.org apt repository. That would have been fine, except that
the maintainer(s) of deb-multimedia.org added an epoch to their versions.
It is not clear to me why this was done, and it breaks the versioned
dependency system, manifesting as frequent bug reports for gimp crashing
on startup.

For example, in #961993, gimp 2.10.18-1 requires the
gegl_rectangle_subtract() function introduced in upstream gegl 0.4.18,
and correctly has a versioned dependency on libgegl-0.4-0 (>= 0.4.22).
Unfortunately, the bug reporter had libgegl-0.4-0 version 1:0.4.16-dmo1
installed. That is an older upstream version 0.4.16, and so does not
have a gegl_rectangle_subtract() function, causing gimp to fail; but
as far as apt/dpkg are concerned, it satisfies the versioned dependency,
because the epoch says it is newer.

Jeremy Bicha contacted deb-multimedia.org and arranged for babl and gegl
to be dropped from the third-party repository, which fixes this problem
for new installations. However, existing installations will still have
their old versions of babl and gegl installed, and will no longer receive
security, bug-fix or feature updates from Debian (because as far as
apt/dpkg know, our versions of babl and gegl are older than the installed
copy).

My intention is to mitigate this by adding a 1: epoch to the versions of
babl and gegl in unstable, and adding the same epoch in the .symbols file
for all symbols introduced since the newest known versions of babl/gegl in
deb-multimedia.org (that's babl 0.1.74 and gegl 0.4.16, unless anyone can
tell me a newer version). This will make Debian's babl and gegl packages
supersede the obsolete versions from deb-multimedia.org. Additionally,
when dependent packages like gimp are next rebuilt, they'll pick up a
dependency on, for example, libgegl-0.4-0 (>= 1:0.4.22), causing the
version from Debian to be installed even if the user is doing a partial
upgrade.

In principle we could add the epoch to only the binary packages,
but it'll be a lot simpler and less confusing to add it to the source
package's version. Some of the binary package names (particularly
libbabl-dev and libgegl-dev) are going to be long-lived, so restricting
the epoch bump to binary packages would not help us to eliminate the
epoch in a future Debian release.

Note that I am specifically only doing this because deb-multimedia.org is
cooperating with us on this issue. Bumping the epoch to 1: in response
to a non-cooperative third-party repo would not be helpful, because
they would respond by bumping the epoch to 2: on their side and we'd
be back where we started; please do not interpret this as precedent for
having Debian packages reflect epochs added in third-party repositories
in general.

It would be a good general rule for third-party packaging repositories to
never add epochs without coordination with Debian. (However, this is of
course unenforceable, because the entire point of third-party repositories
is that they are not controlled by Debian or subject to its policies.)

smcv

Re: epoch bump for babl and gegl libraries

[Adam Borowski]

On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
> The GNOME team intend to add an epoch to the babl and gegl libraries,
> so I'm checking for consensus (Debian Policy §5.6.12.1). As usual with
> epochs, this is a bad situation that I am trying to mitigate as much as
> possible, rather than anything elegant or exemplary.
> 
> babl and gegl are 2D image libraries used by GIMP and GNOME Photos.

> Historically, versions of these packages were shipped by the third-party
> deb-multimedia.org apt repository. That would have been fine, except that
> the maintainer(s) of deb-multimedia.org added an epoch to their versions.

Another option: as these libs are used only by gimp and gnome-photos, you
can add Breaks for the target version range.  This would be ugly but will
make the problem go away in a release or two as the old libs become
non-installable.


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄

introducing an epoch for src:debian-security-support

[Holger Levsen]

hi,

 debian-security-support | 2019.12.12~deb8u2  | jessie-security  | 
source, all
 debian-security-support | 2020.06.21~deb9u1  | stretch  | 
source, all
 debian-security-support | 2020.06.21~deb10u1 | buster   | 
source, all
 debian-security-support | 2020.07.12 | bullseye | 
source, all
 debian-security-support | 2020.07.12 | sid  | 
source, all

is what we currently have in the archive and which is a bit of a hassle to
maintain due to keeping version constraints sane (=newer releases should always
have higher versions) and since rather frequently there are changes only
affecting older releases (so one has to upload to sid first, then do a stable 
update and then update oldstable to propagate something which is only relevant
for oldstable atm.)

Hence I propose to bump the epoch and introduce this versioning scheme:

sid:0:11~2020.08.17
bullseye:   0:11~2020.08.17
buster: 0:10~2020.08.17
stretch:0:9~2020.08.17
and so on.

Right now debian-security-support for stretch and jessie is already maintained
in extra branches, not sure when this will be useful for buster as well.

Feedback welcome.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Religion has been more harmful to humanity than cigarettes.


signature.asc
Description: PGP signature

Re: epoch bump for babl and gegl libraries

[Mattia Rizzolo]

On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
> The GNOME team intend to add an epoch to the babl and gegl libraries,
…
> Historically, versions of these packages were shipped by the third-party
> deb-multimedia.org apt repository. That would have been fine, except that
> the maintainer(s) of deb-multimedia.org added an epoch to their versions.
> It is not clear to me why this was done, and it breaks the versioned
> dependency system, manifesting as frequent bug reports for gimp crashing
> on startup.

Question: what about changing the package name instead, and doing a
transition to a new library package name?  It would be perfect to catch
the occasion of a soname bump, but even then, we are only talking about
less than 10 packages to rebuild for a changed library package name.

> In principle we could add the epoch to only the binary packages,
> but it'll be a lot simpler and less confusing to add it to the source
> package's version. Some of the binary package names (particularly
> libbabl-dev and libgegl-dev) are going to be long-lived, so restricting
> the epoch bump to binary packages would not help us to eliminate the
> epoch in a future Debian release.

This wouldn't solve the problem of the -dev packages having the epoch in
the 3rd party repository, but since you mention that they already
removed the package altogether, I think this is fine: your average user
wouldn't have installed these binaries but only the shared library
binaries, and anybody dealing with building debian packages ought to
keep their system usable enough for that porpuse.  Over time, people who
even had those packages installed would notice somehow… or just
disappear by system reinstallation and whatnot.

> please do not interpret this as precedent for
> having Debian packages reflect epochs added in third-party repositories
> in general.

It's still not so nice though...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: epoch bump for babl and gegl libraries

[Simon McVittie]

On Mon, 17 Aug 2020 at 11:52:46 +0200, Adam Borowski wrote:
> On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
> > The GNOME team intend to add an epoch to the babl and gegl libraries
>
> Another option: as these libs are used only by gimp and gnome-photos

(for completeness: also various gimp plugins)

> you can add Breaks for the target version range.  This would be ugly but
> will make the problem go away in a release or two as the old libs become
> non-installable.

That's more or less what I would have done if deb-multimedia.org wasn't
cooperating. I had a MR open for gegl to make its .symbols file generate
dependencies like "libgegl-0.4-0 (>= #MINVER#), libgegl-0.4-0 (<< 1:0)",
which would have meant the dependent packages wouldn't even need to add
Breaks - any rebuild would have been enough.

However, the correct resolution of that uninstallability is not
immediately obvious: it could be resolved by either "downgrading"
(really upgrading!) babl and gegl, or holding back the dependent
packages. We want the former, and the latter would be harmful.

Since deb-multimedia.org has cooperated with us on this, I think it's
better if we add the epoch and have the upgrade work with no special
action taken.

smcv

Re: epoch bump for babl and gegl libraries

[Simon McVittie]

On Mon, 17 Aug 2020 at 12:29:13 +0200, Mattia Rizzolo wrote:
> On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
> > The GNOME team intend to add an epoch to the babl and gegl libraries,
>
> Question: what about changing the package name instead, and doing a
> transition to a new library package name?  It would be perfect to catch
> the occasion of a soname bump, but even then, we are only talking about
> less than 10 packages to rebuild for a changed library package name.

I am not aware of any upstream plans for a SONAME bump.

Even if there was one planned, libgegl-common is not versioned, so it
has the same problem as the -dev packages.

> This wouldn't solve the problem of the -dev packages having the epoch in
> the 3rd party repository

Or libgegl-common, which unlike the -dev packages will be installed by
all end users of the library.

smcv

Re: Proposal: Allowing access to dmesg for users in group adm

[Marco d'Itri]

On Aug 17, Matthew Ruffell  wrote:

> I propose that we restrict access to dmesg to users in group 'adm' like so:
> 
> 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel.
Which is already the default for Debian.

> 2) Following changes to /bin/dmesg permissions in package 'util-linux'
> - Ownership changes to root:adm
> - Permissions changed to 0750 (-rwxr-x---)
> - Add cap_syslog capability to binary.
Looks good to me.

> 3) Add a commented out '# kernel.dmesg_restrict = 0' to
>/etc/sysctl.d/10-kernel-hardening.conf
Debian does not have this file, so I am not sure if it should be 
introduced just for this.
And what would be the point of setting kernel.dmesg_restrict=0 al long 
as dmesg is still not world-executable?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Proposal: Allowing access to dmesg for users in group adm

[The Wanderer]

On 2020-08-17 at 07:42, Marco d'Itri wrote:

> And what would be the point of setting kernel.dmesg_restrict=0 al long 
> as dmesg is still not world-executable?

As far as I'm aware, it is:


$ dlocate `which dmesg`
util-linux: /bin/dmesg
$ apt-cache policy util-linux
util-linux:
  Installed: 2.36-2
  Candidate: 2.36-2
  Version table:
 *** 2.36-2 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
 2.33.1-0.1 800
800 http://ftp.us.debian.org/debian stable/main amd64 Packages
$ ls -lh `which dmesg`
-rwxr-xr-x 1 root root 83K Aug  1 13:28 /bin/dmesg


Is there some Debian context in which this isn't the case?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Allowing access to dmesg for users in group adm

[Bastian Blank]

Hi

On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote:
> 2) Following changes to /bin/dmesg permissions in package 'util-linux'
> - Ownership changes to root:adm
> - Permissions changed to 0750 (-rwxr-x---)

You mean 0754?

> - Add cap_syslog capability to binary.

Can someone please confirm that filesystem capabilities are restricted
to the current user namespace?  Otherwise this could allow stuff like
containers to read host status.

What happens if using capabilities fail?

Bastian

-- 
Captain's Log, star date 21:34.5...

Re: Proposal: Allowing access to dmesg for users in group adm

[The Wanderer]

On 2020-08-17 at 07:47, Bastian Blank wrote:

> Hi
> 
> On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote:
> 
>> 2) Following changes to /bin/dmesg permissions in package
>> 'util-linux'
>> - Ownership changes to root:adm
>> - Permissions changed to 0750 (-rwxr-x---)
> 
> You mean 0754?

I missed this detail of the proposal. Please ignore my previous mail.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Allowing access to dmesg for users in group adm

[Ansgar]

On Mon, 2020-08-17 at 15:50 +1200, Matthew Ruffell wrote:
> I propose that we restrict access to dmesg to users in group 'adm' like so:
> 
> 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel.
> 2) Following changes to /bin/dmesg permissions in package 'util-linux'
> - Ownership changes to root:adm
> - Permissions changed to 0750 (-rwxr-x---)
> - Add cap_syslog capability to binary.
> 3) Add a commented out '# kernel.dmesg_restrict = 0' to
>/etc/sysctl.d/10-kernel-hardening.conf

That grants additional rights to the `adm` group that it did not have
before, for example to clear the dmesg buffer:

$ dmesg --clear

works after adding `cap_syslog` to the dmesg binary whereas it did not
work before.

Ansgar

Bug#968564: ITP: puppet-module-voxpupuli-posix-acl -- Puppet resource for managing posix-acl

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-voxpupuli-posix-acl
  Version : 1.0.1
  Upstream Author : Vox Pupuli
* URL : https://github.com/voxpupuli/puppet-posix_acl
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet resource for managing posix-acl

 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 plugin module provides a way to set POSIX 1.e (and other standards) file
 ACLs via Puppet.

Re: The "which -s" flag

[Erik Gustafsson]

I took Teemus very good suggestion and changed [-a] to [-as] now :)

https://salsa.debian.org/debian/debianutils/-/merge_requests/6/diffs#ed04ff4dabf1e2d4cd6b89136c2b24dec27ecca4_21_24

Is there anything more I should change?

Who can merge? :)

Den fre 14 aug. 2020 kl 16:07 skrev Simon McVittie :

> On Fri, 14 Aug 2020 at 14:46:39 +0200, Jonas Smedegaard wrote:
> > Regardless of the -s option, why is command preferred over which?  Due
> > to it being POSIX or for some other reason?
>
> * command is POSIX, so any Unixish environment should have it, whereas
>   which is non-standard, so it's anyone's guess whether it will exist
>   on embedded, proprietary or otherwise limited Unixes
>   (some upstream packages don't care about this, and Debian packages never
>   have to, but for some upstream packages it matters)
>
> * relatedly, the which "API" is Unix folklore rather than formally written
>   down, so it's easy to rely on features of one implementation that others
>   don't have, like this -s option; debianutils which only has one option,
>   -a, and GNU which also has that option, but it wouldn't surprise me if
>   implementations exist that don't have -a
>
> * command is a shell builtin (I don't think the spec explicitly says so,
>   but it can't work as documented unless it is), so "command -v java"
>   is faster and more accurately reflects what your shell will actually do
>   when you try to run java, typically on the next line of the same script
>
> smcv
>
>

Re: The "which -s" flag

[Erik Gustafsson]

I understand that if I write my own shell scripts I maybe should use
command -v instead, but this is not for my own shell scripts, but for
compatibility with BSD and Mac.



Den mån 17 aug. 2020 kl 20:47 skrev Erik Gustafsson <
ekir.gustafs...@gmail.com>:

> I took Teemus very good suggestion and changed [-a] to [-as] now :)
>
>
> https://salsa.debian.org/debian/debianutils/-/merge_requests/6/diffs#ed04ff4dabf1e2d4cd6b89136c2b24dec27ecca4_21_24
>
> Is there anything more I should change?
>
> Who can merge? :)
>
> Den fre 14 aug. 2020 kl 16:07 skrev Simon McVittie :
>
>> On Fri, 14 Aug 2020 at 14:46:39 +0200, Jonas Smedegaard wrote:
>> > Regardless of the -s option, why is command preferred over which?  Due
>> > to it being POSIX or for some other reason?
>>
>> * command is POSIX, so any Unixish environment should have it, whereas
>>   which is non-standard, so it's anyone's guess whether it will exist
>>   on embedded, proprietary or otherwise limited Unixes
>>   (some upstream packages don't care about this, and Debian packages never
>>   have to, but for some upstream packages it matters)
>>
>> * relatedly, the which "API" is Unix folklore rather than formally written
>>   down, so it's easy to rely on features of one implementation that others
>>   don't have, like this -s option; debianutils which only has one option,
>>   -a, and GNU which also has that option, but it wouldn't surprise me if
>>   implementations exist that don't have -a
>>
>> * command is a shell builtin (I don't think the spec explicitly says so,
>>   but it can't work as documented unless it is), so "command -v java"
>>   is faster and more accurately reflects what your shell will actually do
>>   when you try to run java, typically on the next line of the same script
>>
>> smcv
>>
>>