Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-09-07 Thread Roger Lynn

On 06/09/2021 11:05, Didier 'OdyX' Raboud wrote:

CUPS appears to already have access to everything in /etc/ssl/ on all
systems, which is where I used to keep my CAcert certificates. This doesn't
feel any different.


You're absolutely right; that's convincing to me!

Reopening, and will fix in the next upload.


Excellent! Thank you.



Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-09-06 Thread Didier 'OdyX' Raboud
Control: reopen -1
Control: tag -1 +pending

Le mercredi, 1 septembre 2021, 22.40:57 h CEST Roger Lynn a écrit :
> On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix
> 
> > Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS,
> > but as that's clearly not a default way of working for CUPS, I'd be
> > _very_ reluctant to allow CUPS to access "all the Let's Encrypt
> > certificates" on all systems it gets installed to. Furthermore,
> > /etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely
> > modifiable by the local system administrator. In other words, imposing
> > that a local system administrator needs to update that file to enable a
> > specific type of certificates is reasonable.
> 
> CUPS appears to already have access to everything in /etc/ssl/ on all
> systems, which is where I used to keep my CAcert certificates. This doesn't
> feel any different.

You're absolutely right; that's convincing to me!

Reopening, and will fix in the next upload.

-- 
OdyX

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


Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-09-01 Thread Roger Lynn

On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix

Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS,
but as that's clearly not a default way of working for CUPS, I'd be
_very_ reluctant to allow CUPS to access "all the Let's Encrypt
certificates" on all systems it gets installed to. Furthermore, 
/etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely

modifiable by the local system administrator. In other words, imposing
that a local system administrator needs to update that file to enable a
specific type of certificates is reasonable.


CUPS appears to already have access to everything in /etc/ssl/ on all 
systems, which is where I used to keep my CAcert certificates. This doesn't 
feel any different.


On 29/08/2021 08:31, Didier 'OdyX' Raboud wrote:

Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit :

The documentation is definitely lacking - I've been trying to work out
why my configuration broke since upgrading to Buster 3 months ago! Even
with the loglevel set to "debug", the logs were utterly unhelpful.
Let's Encrypt is the most popular source of signed certificates and the
upstream documentation at https://www.cups.org/doc/encryption.html
explicitly says:

"CUPS also supports certificates created and managed by the popular
Let's Encrypt certificate service, which are stored in the
/etc/letsencrypt/live directory."


Right. Where do you suggest this needed apparmor edition should be
documented?
README.Debian or cups-files.conf(5) seem appropriate. A mention in 
NEWS.Debian would have been useful, but it's probably a bit late for that now.


Thanks,

Roger



Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-08-29 Thread Didier 'OdyX' Raboud
Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit :
> The documentation is definitely lacking - I've been trying to work out why
> my configuration broke since upgrading to Buster 3 months ago! Even with the
> loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is
> the most popular source of signed certificates and the upstream
> documentation at https://www.cups.org/doc/encryption.html explicitly says:
> 
> "CUPS also supports certificates created and managed by the popular Let's
> Encrypt certificate service, which are stored in the /etc/letsencrypt/live
> directory."

Right. Where do you suggest this needed apparmor edition should be documented?

-- 
OdyX



Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-08-27 Thread Roger Lynn

The documentation is definitely lacking - I've been trying to work out why
my configuration broke since upgrading to Buster 3 months ago! Even with the
loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is
the most popular source of signed certificates and the upstream
documentation at https://www.cups.org/doc/encryption.html explicitly says:

"CUPS also supports certificates created and managed by the popular Let's
Encrypt certificate service, which are stored in the /etc/letsencrypt/live
directory."



Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-08-17 Thread Roger Lynn
Package: cups-daemon
Version: 2.3.3op2-3+deb11u1
Severity: normal
File: /etc/apparmor.d/usr.sbin.cupsd

Adding
  /etc/letsencrypt/archive/** r,
seems to fix this.

I only discovered what was causing the problem when I stumbled across
https://askubuntu.com/questions/1079957

Thanks,

Roger

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages cups-daemon depends on:
ii  adduser3.118
ii  bc 1.07.1-2+b2
ii  init-system-helpers1.60
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-13
ii  libcups2   2.3.3op2-3+deb11u1
ii  libdbus-1-31.12.20-2
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libgssapi-krb5-2   1.18.3-6
ii  libpam0g   1.4.0-9
ii  libpaper1  1.1.28+b1
ii  lsb-base   11.1.0
ii  procps 2:3.3.17-5
ii  ssl-cert   1.1.0+nmu1

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
pn  colord
pn  cups-browsed  
pn  ipp-usb   

Versions of packages cups-daemon suggests:
ii  cups   2.3.3op2-3+deb11u1
ii  cups-bsd   2.3.3op2-3+deb11u1
ii  cups-client2.3.3op2-3+deb11u1
ii  cups-common2.3.3op2-3+deb11u1
ii  cups-filters   1.28.7-1
pn  cups-pdf   
ii  cups-ppdc  2.3.3op2-3+deb11u1
ii  cups-server-common 2.3.3op2-3+deb11u1
ii  foomatic-db-compressed-ppds [foomatic-db]  20200820-1
ii  ghostscript9.53.3~dfsg-7
ii  poppler-utils  20.09.0-3.1
pn  smbclient  
ii  udev   247.3-6

-- Configuration Files:
/etc/cups/cups-files.conf changed:
CreateSelfSignedCerts no
SystemGroup lpadmin
LogFileGroup adm
AccessLog /var/log/cups/access_log
ErrorLog /var/log/cups/error_log
PageLog /var/log/cups/page_log


-- no debconf information