;a=commitdiff;h=0a9f51f58d1e20f92ad2f6a21c70ca04304a7f93
Can you please consider applying this fix in Debian/Squeeze?
Note: this bug leads to DoS of the LDAP server as soon as one issues a query
involving the SQL backend.
Thanks in best regards,
Cédric Dufour
-- System Information:
Debian
Package: firefox-esr
Version: 45.2.0esr-1~deb8u1
Severity: normal
Dear Maintainer,
Since Firefox ESR 45, attempting to install an add-on that requires a
browser restart fails with (at the time of restart):
addons.xpi ERROR Unable to read add-on manifest from
~cdufour/.mozilla/firefox/cdufour.pro
Package: icedove
Version: 1:45.1.0-1~deb8u1
Severity: normal
Dear Maintainer,
Since Icedove 45, attempting to install an add-on that requires a
browser restart fails with (at the time of restart):
ERROR: Unable to read add-on manifest / NS_ERROR_XPC_GS_RETURNED_FAILURE
The problem is exactly id
-information.en.html#entropy-starvation
--
Cédric Dufour - Exoscale (Lausanne, Switzerland)
Workaround: have the hypervisor expose the 'rdrand' CPU feature to the VM
(but this is in the hands of the hypervisor's provider, not the VM user)
ry
4.19.131-1
It *seems* there is already a patch proposed upstream (although here for kernel
4.9): https://lkml.org/lkml/2020/7/20/883
Best regards,
Cédric
--
Cédric Dufour
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
best,
Cédric Dufour
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
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 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
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
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 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
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
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
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
&
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
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
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
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
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
"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
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
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
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 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
The change proposed here should thus not affect too broad an audience.
I know the culprit in all this seems to be OpenVPN but since this bug has been
along for several years and nobody seems to be willing to address it,
would you consider those changes nonetheless ?
Thanks and best,
Cédri
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-
the Debian package does not enable this binary as a
(sysv+systemd) daemon, along creating the ad-hoc system user (e.g. "nvpd") for
it ?
If not, could this be looked into (I can provide input based on my own
re-packaging of the daemon) ?
Thanks for your work and best regards,
Cédri
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
stance(s).
This in particular:
- fixes '/etc/init.d/bind9 status' to fail because of wrong PIDFILE
(because it keeps using its non chroot-ed path)
- allows to specify 'rndc' options, allowing to handle multiple
chroot-ed instances gracefully
I hope this proposal meets your ap
33 matches
Mail list logo
