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
