On 09/01/2019 16:44, Simon Deziel wrote:
> On 2019-01-09 10:23 a.m., Cédric Dufour - Idiap Research Institute wrote:
> ssmtp seems like abandonware. Have you tried msmtp(-mta)? It works in a
> similar way, is well supported and does the right thing when you want TLS.
Indeed. mstmp-mta w
Any chance seeing this issue addressed or its severity lowered, so we can have
the package in Buster ?
Given its purpose - "extremely simple MTA [...]" - should this issue really be
considered "serious" (and Release Critical) ?
PS: ssmtp is extremely handy to forward machine-generated messages
On 03/12/2018 11:58, Andreas Beckmann wrote:
> Patches welcome! (Or a pull request against the repo on salsa.)
Well, maybe even simpler than a patch:
sed 's/__USER__/nvpd/g' \
init/systemd/nvidia-persistenced.service.template \
> debian/nvidia-persistenced.service
sed 's/__USER__/nvpd/g' \
c
--
Cédric Dufour @ Idiap Research Institute
applying those patches as debian/patches ?
Thanks and best,
Cédric
--
Cédric Dufour @ Idiap Research Institute
Description: Fix for OpenVPN bug #538
---
Origin: upstream
Bug: https://community.openvpn.net/openvpn/ticket/538
Bug-Debian: https://bugs.debian.org/772812
Last-Update: 2018-08-28
ric Dufour @ Idiap Research Institute
It seems this problem is adressed more globally as per bug #897599:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897599
Which led to fix for CVE-2018-1108 being reverted (temporarily ?), as per DSA
2018-4096: https://www.debian.org/security/2018/dsa-4196
--
Cédric Dufour @ Idiap Research
ls
(along virtio-rng), haveged, etc.
I was wondering whether this might/ought not to be fixed in autofs itself ?
Best,
Cédric
PS: the (root) issue (kernel RNG blocking at boot) is already being discussed
on LKML: https://lkml.org/lkml/2018/4/29/121
--
Cédric Dufour @ Idiap Research Institute
Would you consider adding this setting to the stock (Debian) libvirtd unit file
?
Thank you very much and best,
Cédric
Other ref: https://answers.launchpad.net/ubuntu/+question/665132
--
Cédric Dufour @ Idiap Research Institute
This issue prevents tinyca2 to retrieve the CA associated
country/organization/etc. and prefill them as default for new
certificates/requests.
Thanks @ Rob for the patch, which I confirm fixes this issue.
Any chance to have this patch included in Stable ?
(it definitely should for Testing and
e *networked* NSS queries (the slow ones).
Just a suggestion, though.
Thank you for your Debian work and best,
Cédric
--
Cédric Dufour @ Idiap Research Institute
Hello,
On 16/12/17 10:02, Carsten Schoenert wrote:
There is the AppArmor profile not re-enable? What let you came to that
conclusion? As written before two commands are needed.
$ sudo rm /etc/apparmor.d/disable/profile.name
$ sudo apparmor_parser -r /etc/apparmor.d/profile.name
It does
Hello Carsten,
On 12/12/17 21:38, Carsten Schoenert wrote:
>>> I think we can implement this change by shipping a symlink to the
>>> profile in /etc/apparmor.d/disable/. My understanding is that dpkg
>>> will treat this removal of a conffile as a change worth preserving on
>>> upgrades, i.e. it
uot;introduces a security hole
allowing access to the accounts of users who use the package" for those who did
rely on AppArmor to control Thunderbird bevahior along attachements.
--
Cédric Dufour @ Idiap Research Institute
kernel-enabled (security=apparmor)
- do the /etc/apparmor.d/disable symlink magic in postinst, based on the
debconf choice
I hope this can be corrected back to Jessie, since this is serious security
issue for those who enabled AppArmor knowingly.
Thanks and best,
Cédric
--
Cédric Dufour @
On 09/08/17 10:02, Cédric Dufour - Idiap Research Institute wrote:
> I confirm this issue is still present is current Debian Stable/Stretch and
> renders CUPS unusable in network printing environments.
> I could backport the packages from testing or experimental, but then I woul
history of CUPS filters/browsed in Debian OldStable/Jessie, it is not something
I'm looking forwards to)
Can we hope in seeing this issue also fixed in Debian Stable/Stretch ?
Thanks for your efforts,
Cédric
--
Cédric Dufour @ Idiap Research Institute
Same here.
Multi/redundant DNS servers do not help, the culprit recursive query being sent
multiple times by client as each DNS server falls in turn.
And multi- firewall/IPS doesn't help catching the faulty packets :-(
I may state the obvious, but only workaround so far is (already saved
I confirm this bug is still present in (now frozen) Stretch and prevents
to setup a stateful redundant load-balancer (e.g. along corosync/pacemaker).
Forementioned patch does solve the issue. It'd be nice if it could be
considered for Stretch (and all upcoming releases): +1 ;-)
Thanks and best,
Hello Brian,
Thank you for your follow up.
There something I don't understand and maybe you can clarifiy it for me (see
below)
On 13/02/16 00:19, Brian Potkin wrote:
> On Wed 10 Feb 2016 at 15:50:53 +0100, Cédric Dufour - Idiap Research
> Institute wrote:
>
>
>> I ha
Hello again,
The issue at hand does not occur on hosts where 'cups-browsed' is also
installed (I guess the cups.service somehow gets "pulled in" by
/etc/systemd/system/multi-user.target.wants/cups-browsed.service; I
don't understand, however, how
/etc/systemd/system/paths.target.wants/cups.path
ible workaround/hack: touch /var/sppol/cups/d)
CUPS starts at boot as expected.
Thank you for considering this report.
Best regards,
Cédric
--
Cédric Dufour @ Idiap Research Institute
Hello
On 21/07/15 17:54, Michael Shuler wrote:
On 07/21/2015 09:05 AM, Cédric Dufour - Idiap Research Institute wrote:
Would you plan to push an updated/backported ca-certificates in
wheezy-updates ?
Would security updates - e.g. removal of a compromised CA - make it to it ?
I'm thinking
Hello,
On 20/07/15 17:30, Cedric Dufour wrote:
On 07/20/2015 09:57 AM, Cédric Dufour - Idiap Research Institute wrote:
In Debian/Wheezy (oldstable), QuoVadis three G3 Root CAs -
https://www.quovadisglobal.ch/Repository/DownloadRootsAndCRL.aspx -
are missing from the 'ca-certificates' package
On 21/07/15 15:45, Michael Shuler wrote:
Do you have a wheezy-updates (previously known as 'volatile') apt line
enabled in your sources.list by default? That repo has far less accidental
upgrade surface than having jessie in sources.list. That might be the better
spot for an updated
it be possible to add them (as we now receive server certificates that
trace back to such G3 root issuing CAs) ?
Thanks and best regards,
Cédric
--
Cédric Dufour @ Idiap Research Institute
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
26 matches
Mail list logo