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' \
i
c
--
Cédric Dufour @ Idiap Research Institute
sider 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-
c
--
Cédric 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
g-tools
(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
Delegate=yes
EOF
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 f
to cache *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 wo
"grave" since it does "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
apparmor package is
installed and 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
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 would
&
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 the
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 co
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 compromis
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 p
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 mi
essie).
Would 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 sub
26 matches
Mail list logo
