You can override ExecStart= by first defining it empty like that:
[Service]
ExecStart=
ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
HTH,
Simon
On 2023-04-17 23:20, J wrote:
Thank you so much, thats exactly what I was missing. I commented out the -p
in
ExecStart=/usr/sbin/unbound -d
When managed by systemd, unbound is started with the "-p" argument that
tells it to not create a PID file at all. I don't know what use you have
for the PID but you can obtain it with:
> systemctl show --property MainPID --value unbound
That's of course assuming unbound is managed by systemd.
Hi,
On 2023-04-15 18:05, أحمد المحمودي (Ahmed El-Mahmoudy) wrote:
A user might manually set XDG_CONFIG_DIR to another path than
$HOME/.config, hence I suggest to add XDG_CONFIG_PATH/msmtp/* to
apparmor profile
AFAIK, Apparmor profiles cannot reference such user defined variables.
HTH,
Simon
On 2023-03-14 08:49, Richard Lewis wrote:
On Mon, 13 Mar 2023, 12:36 Simon Deziel, wrote:
egrep still consumes a lot of memory for me. A workaround I've been
using is to add this to /etc/logcheck/logcheck.conf:
# XXX: prevent grep from using incredible amounts of RAM (>3G
egrep still consumes a lot of memory for me. A workaround I've been
using is to add this to /etc/logcheck/logcheck.conf:
# XXX: prevent grep from using incredible amounts of RAM (>3G RSS)
# this also speeds up grep a lot
export LC_ALL=C
HTH,
Simon
On 2023-02-28 18:37, James Lownie wrote:
It sounds like the problem is at our end then, I will investigate further.
Thanks for helping with this Simon.
Great, please let us know how it goes! Thanks
On 2023-02-28 17:42, James Lownie wrote:
It's not in salsa but it was in my config file. Is it the case that my version
of /etc/apparmor.d/usr.lib.ipsec.charon is different to the package version?
I didn't modify that file manually (apart from moving the lines up in the
file), I did deploy
On 2023-02-28 17:12, James Lownie wrote:
Hi Simon, thanks for the suggestion. I'm going to wait and see if other people
can reproduce this before running any tests, this machine is now in production
which makes things awkward. I would have thought putting the secrets in
On 2023-02-28 00:44, James Lownie wrote:
Version: 5.9.1-1+deb11u3
Package: strongswan-charon
Version: 5.9.1-1+deb11u3
Severity: normal
X-Debbugs-Cc: none
Dear maintainer,
Hello James, I'm not maintainer but I've used strongswan with the
Apparmor profiles.
I ran into a problem using
On 2023-01-19 08:35, Tiger!P wrote:
Package: unbound
Version: 1.17.0-1
Severity: normal
Tags: patch
Dear Maintainer,
* What led up to the situation?
I wanted to configure a static IPv6 address in unbound, but that is not
(always) available when booting the system. Therefor I enabled
This issue was reported in
https://discuss.linuxcontainers.org/t/odd-behavior-with-ubuntu-22-04-and-lxd-22-04-containers/14275
which lead me to report it to Ubuntu in:
https://bugs.launchpad.net/debian/+source/acpid/+bug/1977896
I had not noticed the MR on Salsa so I proposed a very similar
On 2022-05-03 10:20, Michael Tokarev wrote:
03.05.2022 17:08, Simon Deziel wrote:
On 2022-05-03 07:44, Michael Tokarev wrote:
Package: unbound
Version: 1.15.0-8
Severity: normal
When enabling apparmor, unbound fails to start. From the dmesg:
audit: type=1400 audit(1651577812.219:369
On 2022-05-03 07:44, Michael Tokarev wrote:
Package: unbound
Version: 1.15.0-8
Severity: normal
When enabling apparmor, unbound fails to start. From the dmesg:
audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \
operation="mknod" profile="/usr/sbin/unbound" \
There is another difference between /var/lib/unbound/root.key and
/usr/share/dns/root.key: their respective source of update.
The former normally starts its life as a copy of the later but is then
managed using RFC 5011 to cope with root KSK rollovers.
The later being changed only via
On 2022-04-28 13:02, Michael Tokarev wrote:
Control: tag -1 + moreinfo
So, will adding a Recommends: dns-root-data either to libunbound
or to various software packages (eg unbound-host) fix this?
dns-root-data doesn't put the key where unbound-host expects it though:
# unbound-host -D
Here is the merge request:
https://salsa.debian.org/debian/spamassassin/-/merge_requests/7
I have tested on my Ubuntu 20.04 server running a manually patched
spamassassin 3.4.4-1ubuntu1.1
Thank you!
Simon
Package: spamassassin
Version: 3.4.4-1ubuntu1.1
The cron.daily refresh script works well for HTTP mirrors accessed
through a `http_proxy` (thanks to [*]) but fails when accessing HTTPS
mirrors. For those, the HTTPS equivalent variable would need to be
supported.
Thanks,
Simon
*:
On 2021-12-26 06:09, Robert Waldner wrote:
Package: bind9
Version: 1:9.16.22-1~deb11u1
Severity: important
Dear Maintainers,
I upgraded my nameserver from buster to bullseye, afterwards named wouldn't
start anymore.
Looking at syslog, the relevant part seems to be:
...
Dec 26 11:36:01 fsck
I took the patch from Gedalya and proposed it:
https://salsa.debian.org/dns-team/unbound/-/merge_requests/17
Hello
On 2021-06-19 9:52 a.m., nodiscc wrote:
I found 4 msmtp repositories on salsa.debian.org, is it this one?
https://salsa.debian.org/kolter/msmtp
Yes, ^ that's the one. Thanks
Simon
Hi Rajeev,
That seems to be due to a bogus cert chain on the server side. One of
the intermediate expired recently, see the "Not After":
https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.txt
Presumably Thunderbird is a bit more forgiving and uses another chain of
trust but msmtp's
On 2021-02-17 8:30 p.m., Simon McVittie wrote:
On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote:
1) you are worried that since msmtp wasn't written with setgid in mind,
there's a risk of someone elevating their privileges to $USER:msmtp to
execute code
=> Doesn't that just give
Hello Hugo,
On 2021-02-06 11:13 p.m., Hugo Villeneuve wrote:
Source: msmtp
Version: 1.8.3
Severity: normal
Dear Maintainer,
when specifying a custom aliases file in /etc/msmtprc configuration file like
this:
aliases /etc/aliases.msmtp
msmtp returns the following error:
$> echo -e
On 2021-02-03 7:26 a.m., Simon McVittie wrote:
On Tue, 05 Nov 2019 at 10:02:23 -0500, Simon Deziel wrote:
On 2019-11-05 9:29 a.m., Jakub Wilk wrote:
If /etc/msmtprc is readable by group msmtp (as suggested in
README.Debian), any user can acquire password from that file
Nice catch! Having
On 2021-01-28 11:30 a.m., u...@net9.ga wrote:
Package: nsd
Version: 4.1.26-1
Severity: normal
The bottom lines of the package installation were:
Preparing to unpack .../nsd_4.1.26-1_amd64.deb ...
Job for nsd.service failed because the control process exited with error
code.
See
On 2020-11-24 4:23 a.m., Emmanuel Bouthenot wrote:
Hi,
On Tue, Nov 24, 2020 at 12:03:07AM -0500, Simon Deziel wrote:
[...]
Yes, an opt-in approach seems ideal.
Here's the proposal:
https://salsa.debian.org/kolter/msmtp/-/merge_requests/16
Thanks Simon for your merge request.
I'd like
On 2020-11-21 4:02 a.m., Martin Lambers wrote:
On Fri, 20 Nov 2020 10:35:00 -0500, Simon Deziel wrote:
A big problem is that users do not know where to look if they get an
unexplainable "permission denied" error. Almost nobody knows that
AppArmor interferes.
A working AppArmor pro
On 2020-11-20 10:16 a.m., Martin Lambers wrote:
> Package: msmtp
> Version: 1.8.11-2
> Severity: normal
>
> Dear Maintainer,
>
> There are several problems in the Debian AppArmor profile that are frequently
> reported to me as the upstream maintainer, but I cannot fix them since
> I do not ship
Hi Heikki,
On 2020-08-29 4:38 a.m., Heikki Orsila wrote:
> msmtp-mta creates a symlink from "/usr/sbin/sendmail" to "../bin/msmtp".
> It does not use update-alternatives which makes it difficult to install
> msmtp-mta and another MTA on the same system.
In this case, you might want to use the
Package: squid
Version: 4.12-1
In order to do SSL bumping [1], it seems that squid needs to be
configured '--with-openssl'.
I believe that Debian chose to use GnuTLS due to license incompatibility
with OpenSSL. OpenSSL went through the process of re-licensing and were
able to do so in 2017
Hello,
An ubuntu user also ran into this problem [1] as well so I revisited the
patch and turned it into a merge request [2]. I tested the code with
Unbound 1.10.1-1 and chroot set to /var/lib/unbound.
Regards,
Simon
1: https://bugs.launchpad.net/bugs/1885907
2:
On 2020-04-27 11:33 a.m., Scott Bailey wrote:
> buzz:~# journalctl -k -b0 | grep -F apparmor
> buzz:~#
>
> So whatever's going on, it doesn't look like AppArmor has anything to do with
> it.
To completely rule out Apparmor, please share the following:
aa-enabled
sudo aa-status | grep -E
On 2020-04-27 9:34 a.m., Scott Bailey wrote:
> Does anybody have any additional suggestions on what to look at the next time
> I start a troubleshooting session?
Apparmor denials show up in kernel logs, so dmesg/journalctl -k are good
places to look.
sudo journalctl -k -b0 | grep -F
Hi Mark,
On Sun, 22 Sep 2019 15:05:19 +0200 Marc Haber
wrote:
> 1 [4/4992]mh@torres:~ $ sudo systemctl cat openvpn@.service
> /lib/systemd/system/openvpn@.service
> [Unit]
> Description=OpenVPN connection to %i
>
> leads to the misleading output "OpenVPN connection to server" when an
> OpenVPN
Hi Andrej,
On 2020-03-14 11:13 a.m., Andrej Shadura wrote:
> Dear Maintainer,
I'm not the maintainer but have been involved with this Apparmor profile.
> I’m using msmtp with AppArmor, and it cannot connect to gnome-keyring
> unless I add this to the profile:
>
> #include
>
> dbus send
>
Package: openvpn-auth-radius
Version: 2.1-7
In 2010, upstream published a beta release [1] adding those features:
- Implement accounting only feature (option: accountingonly,
default false)
- Implement non fatal accounting (failures during accounting let
the user still connect)
Hi Roger,
On Wed, 28 Aug 2019 18:42:36 +0900 Roger Shimizu wrote:
> Thanks for the hint!
> Yes, I confirm it's an apparmor issue after checking dmesg log.
> And I added one line to /etc/apparmor.d/usr.bin.msmtp to fix my problem.
>
> Enclosed is the patch.
> I think since "dot_msmtprc" can be
Hi Daniele,
On Sun, 20 Oct 2019 23:10:29 +0200 Daniele Tricoli wrote:
> Package: msmtp
> Version: 1.8.6-1
> Severity: wishlist
>
> Hello,
> I recently switched from gpg to python-keyring[¹] to handle the
> password. Could you consider adding keyring as a secret helper?
Sounds reasonable,
Hi Jakub,
On 2019-11-05 9:29 a.m., Jakub Wilk wrote:
> Package: msmtp
> Version: 1.8.6-1
> Tags: security
>
> If /etc/msmtprc is readable by group msmtp (as suggested in
> README.Debian), any user can acquire password from that file:
>
> $ ls -l /etc/msmtprc
> -rw-r- 1 root msmtp 86 Nov
On 2019-11-05 3:30 p.m., Jakub Wilk wrote:
> * Simon Deziel , 2019-11-05, 10:02:
>> Having /etc/msmtprc group readable is AFAIK, a "debianism".
>
> This is my understanding, too.
>
>> I don't know if upstream endorses this method of restricting access to
>>
Hello Francesco,
On 2019-10-16 1:41 p.m., Francesco Ariis wrote:
> Package: msmtp
> Version: 1.8.3-1
> Severity: normal
>
> Dear Maintainer,
>
> I wonder how appropriate the current Apparmor configuration is for
> msmtp. Story time:
>
> - After dist-upgrading my system to buster, my msmtp
Here is a merge request addressing the bug:
https://salsa.debian.org/debian/debianutils/merge_requests/3
Regards,
Simon
Package: debianutils
Version: 4.9
If savelog is invoked as a *normal user* and asked to create files
that are not writeable (-m 0400), it will prompt during mv:
$ savelog -qm 0400 bar
mv: replace 'bar', overriding mode 0400 (r)?
Hi Holger,
I did the exact same thing as you months ago until I noticed the
existence of "openvpn-systemd-resolved" that happens to be a "suggested"
package:
On 2019-09-19 7:37 a.m., Holger Mueller wrote:
...
> Versions of packages openvpn suggests:
> ii openssl 1.1.1c-1
> pn
On 2019-08-28 5:42 a.m., Roger Shimizu wrote:
> control: severity -1 wishlist
> control: tag -1 +patch
>
> Dear Simon,
>
> On Tue, Aug 27, 2019 at 1:26 AM Simon Deziel wrote:
>>
>> This permission denied is likely due to Apparmor not letting msmtp
>> access a
Hello Roger,
On 2019-08-26 11:41 a.m., Roger Shimizu wrote:
> I tried to put my .msmtprc to somewhere else than $HOME, and just make a
> symbolic link to $HOME. But msmtp refused to read that way and report:
>
>
> $ msmtp -v -t < ../email.txt
> ignoring system configuration file
Hello Vincent,
On 2019-07-31 9:49 a.m., Vincent Hobeïka wrote:
> Package: msmtp
> Version: 1.8.3-1
> Severity: normal
>
> Dear Maintainer,
>
> msmtp is unable to write logs into an encfs file. If I try to write
> the logs elsewhere everything is fine.
>
> I believe I have the same problem
Hello,
On 2019-08-03 4:29 a.m., VA wrote:
> Package: msmtp
> Version: 1.8.3-1
>
> msmtp is capable of reading SMTP passwords in a conf file, using an
> external command, or reading it on the TTY. So it tests by opening
> /dev/tty:
>
>
Hello,
On 2019-05-02 10:58 a.m., Carsten Schoenert wrote:
> Hi,
>
> Am 02.05.19 um 09:05 schrieb Ulrike Uhlig:
>>> Well, but who has enabled AA in PC? I'm sure that I have not worked on
>>> /etc in these days and I am the only one can access on it. In my opinion
>>> there is a bug in some
Hi,
On 2019-04-30 5:05 a.m., Piviul wrote:
> Il 30/04/19 10:31, Ulrike Uhlig ha scritto:
>> Hi!
>>
>> On 30.04.19 09:31, Piviul wrote:
>>> Il 30/04/19 07:51, Carsten Schoenert ha scritto:
>>
downgrading severity as AppArmor isn't officially supported and
activated for the Thunderbird
On 2019-04-25 9:41 a.m., Simon Deziel wrote:
> I'll soon be proposing a fix via salsa.
https://salsa.debian.org/debian/strongswan/merge_requests/4
signature.asc
Description: OpenPGP digital signature
Package: strongswan
Version: 5.7.1-1
Hello,
A user on Ubuntu reported [1] that Strongswan 5.7.1-1 no longer worked
with privilege downgrade. He also traced the root cause to a missing
capability: CAP_SETPCAP.
I'll soon be proposing a fix via salsa.
Thanks,
Simon
1:
Hi Christoph,
On Fri, 12 Aug 2016 19:09:40 +0200 Christoph Egger
wrote:
> It's a bit unfortunate that tls_fingerprint pinns the server
> certificate instead of the public key. Especially with the new kid
> letsencrypt certificate turnover times are getting even shorter all
> the time while
On 2019-02-09 8:28 p.m., Robert Edmonds wrote:
> Probably it's better to use the --with-chroot-dir= argument to configure
> rather than directly patching the source to change the default.
Indeed and that's what's being proposed in the merge request.
Regards,
Simon
On 2019-02-08 7:26 a.m., Kepi wrote:
> Chroot workaround is working for me too.
Good.
> Anyway in the long term would it be better to have chroot setup
> automatically again? I found out that it was working before, at least
> some work was done in #579622 for auto support.
The auto-chroot setup
On 2019-01-20 3:59 p.m., Ondřej Surý wrote:
> That seems overly complicated for a little gain. dns-root-data has the
> current root key and keeps it up-to-date for all DNS related packages.
Here's a much simpler fix:
https://salsa.debian.org/dns-team/unbound/merge_requests/4
Regards,
Simon
Here is a merge request [*] to disable chroot'ing again like it has been
since version 1.0.0-3
Regards,
Simon
*: https://salsa.debian.org/dns-team/unbound/merge_requests/3
signature.asc
Description: OpenPGP digital signature
Hi Ryan,
On 2019-02-06 11:12 a.m., Ryan Kavanagh wrote:
> Since the upgrade to 1.9.0-1, unbound fails to start. Purging the
> package and reinstalling does not fix the issue. The errors seem to be
> due to being unable to read various configuration files.
>
> Feb 06 11:01:12 zeta unbound[28647]:
Hi Julian,
On 2019-01-16 1:53 p.m., Julian Andres Klode wrote:
> The unbound package runs dh_apparmor too late, causing the generated postinst
> to have dh_enable_systemd parts run first, which enable and start the service.
>
> Because the process is already running the parts added by
On 2019-01-20 3:59 p.m., Ondřej Surý wrote:
> That seems overly complicated for a little gain. dns-root-data has
> the current root key and keeps it up-to-date for all DNS related
> packages.
Boiler plate aside, it essentially turns unbound-anchor into a daily job
that keeps the root.key current
Inspired by discussions on the unbound-users list [1] and what other
distros (SLES, Fedora) are doing to keep the root.key current and make
it available for other unbound related packages I came up with this
merge request [2]. Comments and suggestions are welcome.
Thanks,
Simon
1:
Hello Mantas,
On 2019-01-15 7:59 a.m., Mantas Mikulėnas wrote:
> 1. the traditional @{HOME}/.msmtprc, and
> 2. the XDG Basedir compatible @{HOME}/.config/msmtp/config
>
> The new AppArmor profile is missing the latter path. I think both
> default locations should be included in the standard
On 2019-01-14 6:03 p.m., Sergio Mendoza wrote:
> Yes. I have now checked and I have .msmtprc as a symlink. If it is not
> a symlink then I have no problems and everything runs smooth.
Great, thanks Sergio.
> In any case
> this is the output you asked for:
>
> root@quetzalli:~# dmesg | grep
Hi Sergio,
On 2019-01-14 5:40 p.m., Sergio Mendoza wrote:
> A few days ago, msmtp fails to work. It all seems to be related to the
> inability to read ~/.msmtprc file. In other words it seems that
> ~/.msmtprc needs to have mode 644. This is not at all desired since
> sensible (private)
On 2019-01-14 1:42 p.m., demuredemeanor wrote:
> After testing this new configuration (and retesting after removing my
> temporary apparmor force-complain symlink) msmtp seems to working for
> both `pass` and the GNU stow symlink.
Thanks for the testing and feedback!
Hi Robbie,
On 2019-01-14 5:28 p.m., Robbie Harwood wrote:
> Package: msmtp
> Version: 1.8.1-2
> Severity: important
>
> Dear Maintainer,
>
> Trying to send mail with msmtp after upgrading, it fails with "no
> configuration file available". The audit line is:
>
> audit: type=1400
On 2019-01-14 11:17 a.m., Gard Spreemann wrote:
>
> Simon Deziel writes:
>
>> Would you mind testing this base profile [1] and report back. If it
>> still doesn't work for you, please provide the denial logs from dmesg.
>
> It works well! I realize that the game of a
Hi Jani,
On 2019-01-14 5:17 a.m., Jani Nikula wrote:
> I store my dotfiles in a git repo, and symlink the actual dotfiles to
> the git checkout. After msmtp update, the AppArmor profile blocked this:
>
> [622972.288769] audit: type=1400 audit(1547459536.817:103): apparmor="DENIED"
>
On 2019-01-14 9:52 a.m., Gard Spreemann wrote:
> Thanks to the maintainer for taking care of things so quickly.
>
> Could perhaps the NEWS file be expanded a little bit, though? I would
> not be surprised if my setup is quite common: I use
>
> passwordeval /usr/bin/pass foo | head -n 1
Yes,
On 2019-01-14 5:32 a.m., demuredemeanor wrote:
> The apparmor change has royally broken my neomutt+msmtp.
>
> The two big issues this brings to me is 1) I use `pass` (
> https://www.passwordstore.org) as my password manager with passworleval and
> 2) as a user of GNU Stow for my dotfiles apparmor
Hi Jani,
On 2019-01-14 5:17 a.m., Jani Nikula wrote:
> Package: msmtp
> Version: 1.8.1-2
> Severity: important
>
> Dear Maintainer,
>
> I store my dotfiles in a git repo, and symlink the actual dotfiles to
> the git checkout. After msmtp update, the AppArmor profile blocked this:
>
>
On 2019-01-14 5:32 a.m., demuredemeanor wrote:
> The apparmor change has royally broken my neomutt+msmtp.
>
> The two big issues this brings to me is 1) I use `pass` (
> https://www.passwordstore.org) as my password manager with passworleval and
I think this helper should be easy and safe to
The updated Apparmor profile and debian/NEWS were proposed for
integration: https://salsa.debian.org/kolter/msmtp/merge_requests/1
Regards,
Simon
On 2019-01-10 9:54 a.m., Kai Weber wrote:
> * Simon Deziel :
>
>> Actually, please use this new attached profile which is identical in
>> purpose but uses better names.
>
> The profile works with the secret-tool solution.
Great, thanks for testing, I really appreciate i
On 2019-01-09 8:57 p.m., Simon Deziel wrote:
> Could you give a try to the attached profile and report back?
Actually, please use this new attached profile which is identical in
purpose but uses better names.
Thanks,
Simon
# Author: Simon Deziel
#include
/usr/bin/msmtp fl
probably not widely
used if I'm not mistaken. The secret-tool one should be common though
and needs work. Could you give a try to the attached profile and report
back?
Regards,
Simon
# Author: Simon Deziel
#include
/usr/bin/msmtp flags=(attach_disconnected) {
#include
#include
#
On 2019-01-09 10:23 a.m., Cédric Dufour - Idiap Research Institute wrote:
> PS: ssmtp is extremely handy to forward machine-generated messages in large
> deployments, internally, iow. where TLS is not required
ssmtp seems like abandonware. Have you tried msmtp(-mta)? It works in a
similar way,
Hi Kai,
On 2019-01-09 10:03 a.m., kai.we...@glorybox.de wrote:
> With the AppArmor profile shipped the 'passwordeval' options does not
> work anymore. I tried using the permitted "gpg" or "secret-tool" but
> this did not work.
>
> msmtp uses popen(3) which in turn seems to exec /bin/dash which
Hi,
On 2019-01-08 5:03 p.m., Emmanuel Bouthenot wrote:
> On Mon, Jan 07, 2019 at 08:35:25PM -0500, Simon Deziel wrote:
> [...]
>
>> I agree, I should have thought of that. How about adding the text from
>> README.Debian as a NEWS entry?
>>
>> I
ing the text from
README.Debian as a NEWS entry?
I will do some testing with 1.8.1-1 but in the meantime, please find
attached a more up to date profile that received more testing and also
incorporates your feedback (thanks!).
Regards,
Simon
# Author: Simon Deziel
#include
/usr/bin/msmtp f
Package: nsd
Version: 4.1.25-3
Hello,
I noticed the switch to Type=notify (yay!) and when playing with the
unpublished version (4.1.25-3), I found some things that could be
improved which lead me to open this merge request [1].
Regards,
Simon
1:
Hello Timo,
On 2018-11-09 8:13 a.m., Timo Sigurdsson wrote:
> However, I believe the patch is not fully correct. With the proposed
> patch, mounting of the notify socket is done unter the condition that
> $CHROOT_DIR and $UNBOUND_BASE_DIR are *not* equal. This means that
> the socket will not be
Package: openvpn
Version: 2.4.6-1
Hello,
On machines using systemd-resolved, the recommended way to configure
per-link DNS and search domains is via the systemd-resolve command. As
such, I sent a merge request to implement this [1]. I'd be happy if you
could take a look at the merge request.
On 2018-11-01 10:40 a.m., Timo Rothenpieler wrote:
> I don't have a ~/.ssh/config, only an ed25519 and rsa4096 key pair
> without passwords.
> /etc/ssh is untouched one from the packaged files.
>
> This whole setup is running in a VMWare Workstation VM, Windows 10 is
> the host.
Could this be
On 2018-09-19 05:18 AM, Guido Günther wrote:
> Hi,
> On Wed, Jan 10, 2018 at 10:36:51AM +0100, Guido Günther wrote:
>> Hi,
>> On Wed, Jul 13, 2016 at 10:27:11AM +0200, Guido Günther wrote:
>>> On Tue, Aug 24, 2010 at 12:23:52PM +0200, Michael Prokop wrote:
Package: openssh-server
On Mon, 25 Sep 2017 09:52:17 +0200 Herman van Rink wrote:
> On Wed, 12 Jul 2017 17:38:10 +1000 Russell Coker
> wrote:
> > I've attached the patch I use to deal with this. While this patch may
> not be
> > suitable for a Debian package I think that it's worth sharing so other
> users
> > can make
On Sun, 27 May 2018 18:01:01 -0400 Simon Deziel wrote:
> A possible solution would be to have libunbound2 depend on
> unbound-anchor and have the unbound-anchor package ship a cron job (or
> systemd.timer unit) to periodically refresh the root.key file.
After some research, Fedor
Package: unbound
Version: 1.7.1-1
TL;DR: applications using libunbound2 should have access to a fresh root.key
If one installs unbound-anchor or unbound-host or any other application
using libunbound2, they will be missing a fresh copy of the root.key for
DNSSEC validation. This is because
On Sat, 2 Dec 2017 14:39:00 -0500 Simon Deziel <si...@sdeziel.info> wrote:
> Please find attached a patch that:
>
> * Removes world read access to /etc/msmtprc and chgrp to "mail".
> * Installs the msmtp binary as setgid and owned by "root:mail".
Seth Arnold
Hi Carsten,
On 2018-04-05 11:22 AM, Carsten Schoenert wrote:
> could you please have a look at this?
> I can't overview any side effects if the suggested change would be
> applied. Thanks!
The revised patch looks good and legitimate.
Regards,
Simon
Hi Robert,
On 2018-02-28 01:08 PM, Simon Deziel wrote:
> I couldn't find a way to do the merge proposal through the WebUI of
> salsa (maybe because I'm a -guest). Please see the refreshed Apparmor
> profile at [1]. Feedback is welcome of course!
>
> 1: https://salsa.debian.or
> I get a 404 on that URL, and your repository doesn't show up under:
>
> https://salsa.debian.org/users/sdeziel-guest/projects
>
> Maybe your GitLab visibility settings are misconfigured.
Yes indeed. Projects default to private, fixed and tested. Sorry for the
back and forth it's my first
On 2018-02-28 11:48 AM, Simon Deziel wrote:
> Yes, I'm working on a pull request/merge proposal via salsa.debian.org.
> I'll be proposing a fix for all 3 Apparmor related bugs with the Unbound
> profile. Shouldn't be too long. Thanks!
I couldn't find a way to do the merge proposa
Hello Robert,
On 2018-02-28 11:31 AM, Robert Edmonds wrote:
> Did you mean to include the fix in your bug report?
Yes, I'm working on a pull request/merge proposal via salsa.debian.org.
I'll be proposing a fix for all 3 Apparmor related bugs with the Unbound
profile. Shouldn't be too long.
Package: unbound
Version: 1.6.7-1
Dear maintainer,
An Ubuntu user reported an issue [1] with the unbound's Apparmor profile
that prevents unbound from chown'ing and chmod'ing the Unix control
socket if used (non-default). To reproduce:
# cat << EOF >
Package: netdata
Version: 1.9.0+dfsg-1
Dear maintainer,
When installing netdata in a (LXD) container I noticed the setcap call
would fail during postinst.
I believe this is because file capabilities can only be set in the
original namespace unless you run a 4.14+ kernel which includes [1].
Package: tor
Version: 0.3.3.1-alpha-1
Severity: minor
Hi Peter,
While looking at the systemd units, I noticed an unusual (to me) mode
used by install when creating the directory under /var/run:
ExecStartPre=/usr/bin/install -Z -m 02755 -o ... -d /var/run/...
When looking in chmod(1) and
On 2018-01-30 03:40 PM, Robert Edmonds wrote:
> Simon Deziel wrote:
>> On 2017-11-27 09:22 AM, Peter Palfrader wrote:
>>> On Mon, 27 Nov 2017, Simon Deziel wrote:
>>>
>>>> On 2017-11-26 03:31 AM, Peter Palfrader wrote:
>>>>> The apparmor poli
Hi,
In addition to what Russ proposed to add, I've been running with those
additional restrictions:
SystemCallArchitectures=native
# note: AF_NETLINK is needed for getifaddrs(3)
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
They are available on older systemd versions so they
Alright, makes sense, thanks for the quick update.
signature.asc
Description: OpenPGP digital signature
1 - 100 of 226 matches
Mail list logo
