Re: Which Debian packages leak information to the network?

On Thu, May 19, 2016 at 7:56 AM, georg wrote: > On 16-05-18 16:54:27, Holger Levsen wrote: >> gnome-calculator contacts a web page/service with currency exchange >> information *on every start*, > > Is this "publicly" known? Is this discussed with the upstream devs?

Re: Debian SHA-1 deprecation

On Wed, May 18, 2016 at 9:20 PM, Daniel Pocock wrote: > Can anybody comment on how Debian users will be impacted by SHA-1 > deprecation? There is some info related to that in these two wiki pages: https://wiki.debian.org/SHA-1 https://wiki.debian.org/Teams/Apt/Sha1Removal -- bye, pabs

Re: Which Debian packages leak information to the network?

On 16-05-18 16:54:27, Holger Levsen wrote: > gnome-calculator contacts a web page/service with currency exchange > information *on every start*, Is this "publicly" known? Is this discussed with the upstream devs? signature.asc Description: Digital signature

Re: debcheckroot v1.0 released

On Wed, May 18, 2016 at 06:07:00PM +0200, Elmar Stellnberger wrote: > Well; you are right Patrick; [ ... snip ... ] Other thing that Patrick does right, is making it possible to read in discussion order Please reply below the text

Re: Which Debian packages leak information to the network?

On Wed, May 18, 2016 at 06:33:52PM +0200, Jakub Wilk wrote: > Could you explain how any of these tools leak any information "without a > user's consent/expectation"? gnome-calculator contacts a web page/service with currency exchange information *on every start*, I think that's a good example of

Re: Which Debian packages leak information to the network?

* Patrick Schleizer , 2016-05-18, 15:50: we are a privacy-centric distro based on Debian and wanted to know what Debian packages leak information about the system to the network without a user's consent/expectation. As documented on the page below, a system's security

Re: debcheckroot v1.0 released

Well; you are right Patrick; perhaps I should do something to awake debcheckroot from its slumber! If I am not the one who can build a respective infrastructure around the project (i.e. checksums for all Debian packages) and develop the code forth then someone else would do it as there seems

Which Debian packages leak information to the network?

Hello we are a privacy-centric distro based on Debian and wanted to know what Debian packages leak information about the system to the network without a user's consent/expectation. As documented on the page below, a system's security also depends on avoiding leaking any identifiable information

Re: debcheckroot v1.0 released

Elmar Stellnberger: > Dear Debian-Security > > Having just released debcheckroot I wanna shortly present you my new tool: > It was originally designed as a replacement for debsums and has the following > qualities: > * full support of Debian repos reading /etc/[apt/]sources.list to fetch >

Re: Debian SHA-1 deprecation

Am 2016-05-18 um 15:20 schrieb Daniel Pocock: Can anybody comment on how Debian users will be impacted by SHA-1 deprecation? In particular: - will libraries like OpenSSL and GnuTLS continue to support it in stretch and beyond? - will web servers like Apache support it in server certificates

Problems in https://www.debian.org/doc/manuals/securing-debian-howto

1. https://www.debian.org/doc/manuals/securing-debian-howto/ch-automatic-harden.en.html#s6.2 describes Bastille Linux which is no longer in Debian. 2. Should there be information on AppArmor and SELinux (other than footnote 66]?

Debian SHA-1 deprecation

Can anybody comment on how Debian users will be impacted by SHA-1 deprecation? In particular: - will libraries like OpenSSL and GnuTLS continue to support it in stretch and beyond? - will web servers like Apache support it in server certificates or certificate chains? - will web servers and

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

The Android SDK is really probably more like Eclipse. About 5 years of support, they are still maintaining Android 2.3.3 to some degree and that's at least 5 years old. https://android.stackexchange.com/a/84816 Also, the security profile is relatively low risk for the Android SDK in general: *

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

BoringSSL is just a part of the Android SDK. It has an unstable API because it is only the C backing to a single Java library called conscrypt. That library is in turn only used as part of the Android SDK. Using the upstream build system, all of the source code is checked out at once from many

External check

CVE-2015-4116: TODO: check CVE-2016-2803: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run.