Bug#992079: salt-master should have write access to /etc/salt
Package: salt-master Version: 3002.6+dfsg1-4 Severity: Normal While the official packages run salt-master as root, the Debian packages run salt-master under the user "salt". I have written a plug-in for Salt that provides dynamically generated pillars for encryption keys, passwords, and other useful features (shameless plug: https://github.com/jdelic/dynamicsecrets). However, dynamicsecrets needs to save data to a permanent location in the form of a sqlite database. The default path for that is /etc/salt/dynamicsecrets.sqlite. Of the folders owned by the salt-master package, this is the logical choice since /var/cache/salt and /var/run/salt are ephemeral locations. Unfortunately on the Debian packages the "salt" user has no write access to /etc/salt. Salt's own documentation (https://docs.saltproject.io/en/latest/ref/configuration/nonroot.html) under "Running the Salt Master/Minion as an Unprivileged User" states """ In order to allow Salt to successfully run as a non-root user, ownership, and permissions need to be set such that the desired user can read from and write to the following directories (and their subdirectories, where applicable): /etc/salt /var/cache/salt /var/log/salt /var/run/salt """ Unfortunately there is no way to fix this from within dynamicsecrets as the "salt" user doesn't have write access to any location amenable to long-term storage. So I would ask the package to be updated to change the owner of /etc/salt to be owned by the "salt" user.
Bug#992064: greylistd should not recommend installation of exim4
Package: greylistd Version: 0.9.0 Severity: Normal The greylistd package currently recommends exim4. I wrote a filter for OpenSMTPD that uses greylistd for providing greylisting services (shameless plug: https://github.com/jdelic/opensmtpd-filter-greylistd/). With the current package, if the user tries to install greylistd without --no-install-recommends, apt will happily uninstall OpenSMTPD to install exim4. This is not ideal from a user-experience point of view. I think the best solution is for greylistd to merely _suggest_ exim4. If we want to keep the recommendation, an alternative solution would be to recommend the "mail-transport-agent" meta package. This way OpenSMTPD would also fulfill the recommendation. What do y'all think?
Bug#911925: openjdk-8-jdk: Maven surefire crashes after update to 8u181-b13-2
found 911925 8u181-b13-2~deb9u1 thanks We have encountered this bug with the latest security patch level as well. cheers Jonas
Bug#911925: openjdk-8-jdk: Maven surefire crashes after update to 8u181-b13-2
We discovered this bug as well and it is indeed the result of the patch
applied in S8195874.
To be precise the patch is here:
https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac
But upstream OpenJDK applied a follow-up:
https://hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8
The second patch defines a default ("true") for
"jdk.net.URLClassPath.disableClassPathURLCheck". @Erich: This is why
this problem currently only applies to Debian's openjdk-8 build.
For now the only available workarounds are downgrading to a previous
build or setting the property.
Best regards,
Jonas
