Re: Bug#1093650: Prebuilt binaries in QEMU source

20.01.2025 23:53, Michael Tokarev wrote: 20.01.2025 23:49, Heinrich Schuchardt wrote: Hello Michael, I can understand that a maintainer cares about keeping his package buildable but system security is of even higher importance. The xz package has demonstrated the security impact of

Re: Bug#1093650: Prebuilt binaries in QEMU source

20.01.2025 23:49, Heinrich Schuchardt wrote: Hello Michael, I can understand that a maintainer cares about keeping his package buildable but system security is of even higher importance. The xz package has demonstrated the security impact of including binaries of unchecked origin. Why do

Re: sysadmin in training

r bad scripts there. While I agree pulling third scripts with curl is cringe-worthy I think Ossec HIDS is an exception because it is GNU Public licensed. Michael Lazin .. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι. On Fri, May 12, 2023 at 3:33 PM Jeffrey Chimene wrote: > On 5/12/23 10:16, Jeremy

Re: What is the best free HIDS for Debian

. This method will not find deleted files so some expertise in the Linux file system is necessary when not using rkhunter. Thanks, Michael Lazin On Mon,May 9, 2022 at 4:04 AM Elmar Stellnberger wrote: > Am 09.05.22 um 00:48 schrieb Tomasz Ciolek: > > 5. have we eliminated other cause

Re: What is the best free HIDS for Debian

Rkhunter does find patterns of known rootkits but it also finds indicators like memory anomalies like I mentioned and it logs each file change from the install, this is why ideally you should install it in a fresh system. Thanks. Michael Lazin On Sun, May 8, 2022 at 3:45 PM wrote: >

Re: What is the best free HIDS for Debian

strengthened by key signing which is more common in the Debian community. Thank you. Michael Lazin On Sun, May 8, 2022 at 2:43 PM wrote: > Am 08.05.22 um 20:21 schrieb Michael Lazin:> I think if you have a root > kit it is very unlikely to get rid of it > > without backing up and reimaging

Re: What is the best free HIDS for Debian

malware that resides in memory. Apparmor is included in Debian. Thanks, Michael Lazin On Sun, May 8, 2022 at 11:18 AM Sylvain wrote: > Dear Elmar, > > Thank you for your help. I really appreciate very much. > > I thought a lot about your answer and I feel a bit tricky... I > unde

Re: Ddos

You’ll have to be a little more specific than that Im afraid. > On 2 May 2022, at 01:55, Christopher Jennings > wrote: > > Help with vulnerabilities

Re: amd64 running on Intel Celeron and Pentium?

On Sun, Apr 17, 2022 at 10:05:39AM +0200, Friedhelm Waitzmann wrote: vendor_id   : GenuineIntel cpu family  : 15 model   : 2 model name  : Intel(R) Pentium(R) 4 CPU 2.00GHz stepping    : 4 cpu MHz : 1993.656 cache size  : 512 KB ? Celeron 440 for sure is 64-

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Thu, Apr 14, 2022 at 02:34:22PM +0200, Elmar Stellnberger wrote: On Wed, Apr 13, 2022 at 03:11:04PM -0400, Michael Stone wrote: On Wed, Apr 13, 2022 at 08:18:30PM +0200, Levis Yarema wrote: > What about Spectre /Meltdown? P3/P4/Pentium M systems don´t have that? Core 2 > systems

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Wed, Apr 13, 2022 at 08:18:30PM +0200, Levis Yarema wrote: What about Spectre /Meltdown? P3/P4/Pentium M systems don´t have that? Core 2 systems to my knowledge can. There's no reason to believe netburst systems are not affected by any of the cpu issues identified in the past few years, but

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Wed, Apr 13, 2022 at 07:18:53PM +0200, Levis Yarema wrote: If I would get an x64 CPU from a Linux pro, sure I would take it. Otherwise I would not recommend to just take any old hardware for exchange with my working one since not all of it was easily well supported by Linux these days, as far

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Wed, Apr 13, 2022 at 05:32:10PM +0200, Odo Poppinger wrote: I have a beloved P4 Gericom Frontman and I do not want to give it away. and that's fine, but it's increasingly unreasonable to try to run a modern general purpose OS on hardware that's 20 years old. if the driver is nostalgia, som

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Wed, Apr 13, 2022 at 03:44:00PM +0100, piorunz wrote: On 12/04/2022 04:59, Friedhelm Waitzmann wrote: You mean, that it is possible to run amd64 on my old hardware 1# vendor_id   : GenuineIntel cpu family  : 6 model   : 22 model name  : Intel(R) Celeron(R) CPU  4

Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?

On Wed, Jan 13, 2021 at 09:49:43PM +0100, Christoph Pflügler wrote: [    0.00] microcode: microcode updated early to revision 0xd6, date = 2019-10-03 [    0.379026] SRBDS: Vulnerable: No microcode [    1.625090] microcode: sig=0x506e3, pf=0x2, revision=0xd6 [    1.625215] microcode: Microcod

Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?

On Tue, Jan 12, 2021 at 05:25:23PM +0100, Giacomo Catenazzi wrote: In any case, according Intel, microcode should be updated by BIOS I wonder if anyone from intel can manage to say that with a straight face.

Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?

On Fri, Jan 08, 2021 at 10:48:30PM +0100, Christoph Pflügler wrote: On 08.01.21 22:34, Michael Stone wrote: On Fri, Jan 08, 2021 at 09:12:53PM +0100, Christoph Pflügler wrote: Installing package intel-microcode in Debian 10 (Buster) mitigates most vulnerabilities as per spectre-meltdown

Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?

On Fri, Jan 08, 2021 at 09:12:53PM +0100, Christoph Pflügler wrote: Installing package intel-microcode in Debian 10 (Buster) mitigates most vulnerabilities as per spectre-meltdown-checker. However, CVE-2018-3640 and CVE-2018-3615 are still displayed as unmitigated after reboot, with spectre-mel

Re: Intel Microcode updates

On Tue, Jun 11, 2019 at 08:00:49PM +0200, Davide Prina wrote: On 10/06/19 20:31, Michael Stone wrote: On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote: On 10/06/19 13:16, Michael Stone wrote: Your CPU is not supported my Intel, so you either accept the risk or buy a new one. you

Re: Intel Microcode updates

On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote: On 10/06/19 13:16, Michael Stone wrote: Your CPU is not supported my Intel, so you either accept the risk or buy a new one. you have another choice: disable the SMP & C. and all mitigation form Linux That's not correct,

Re: Intel Microcode updates

On Mon, Jun 10, 2019 at 02:01:25PM +1000, Russell Coker wrote: I just discovered the spectre-meltdown-checker package (thanks Sylvestre for packaging this). model name : Intel(R) Core(TM)2 Quad CPUQ9505 @ 2.83GHz On a system with the above CPU running Debian/Testing I get the followin

Re: patch: Mark CVE-2018-1384{3,4,5} as fixed in htslib 1.9-1

[adding the Debian Med Project List in CC] În dum., 9 dec. 2018 la 11:28, Michael Crusoe a scris: > Dear colleagues, > > Attached is a patch to mark CVE-2018-1384{3,4,5} as fixed in htslib 1.9-1. > > I also submitted a pull request > https://salsa.debian.org/security-tra

patch: Mark CVE-2018-1384{3,4,5} as fixed in htslib 1.9-1

h the security-team/CVEs; please let me know if I'm not doing this correctly or could do it better. Thanks! -- Michael R. Crusoe Co-founder & Lead, Common Workflow Language project <http://www.commonwl.org/> Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania Debian Maintain

Re: Security support for chromium in jessie

On Tue, Aug 15, 2017 at 1:09 PM, Emilio Pozuelo Monfort wrote: > I think we should do this for as long as it's reasonably possible, given > firefox > updates will get harder and harder (they will require newer versions of rustc, > which may need to be bootstrapped) so having another supported brow

Security support for chromium in jessie

Hi all, I do not have enough free time to be able to keep up with security updates to chromium in jessie (oldstable) any more. It is technically feasible to keep it working in a jessie environment, but each update has been more and more work. I expect that to continue. Anyway, if anyone would l

Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?

On Thu, Oct 13, 2016 at 02:45:29PM -, te3...@sigaint.org wrote: As you asked me for a specific case, may I bring up CVE-2016-5696. A fix to the medium-risk vulnerability was uploaded on July 10, 2016 by Eric Dumazet (cf. https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455b6822ab09e5

Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?

On Wed, Oct 12, 2016 at 10:43:41AM -, te3...@sigaint.org wrote: 1. If I understood correctly the contents of your reply, on what basis does the Debian security team assess the severity of each security vulnerability? What are those criteria? You'll find that there's a lot of criticism of CV

Re: Bug#839607: Robustify manager_dispatch_notify_fd()

Am 03.10.2016 um 12:11 schrieb Michael Biebl: > Am 03.10.2016 um 08:22 schrieb Wolfgang Karall: >> Hello Michael, >> >> On 16-10-02 22:36:00, Michael Biebl wrote: >>> The news about systemd crashing when getting a zero sized message >>> on the notification

Re: Bug#839607: Robustify manager_dispatch_notify_fd()

Am 03.10.2016 um 12:11 schrieb Michael Biebl: > Am 03.10.2016 um 08:22 schrieb Wolfgang Karall: >> Hello Michael, >> >> On 16-10-02 22:36:00, Michael Biebl wrote: >>> The news about systemd crashing when getting a zero sized message >>> on the notification

Re: Robustify manager_dispatch_notify_fd()

Am 03.10.2016 um 08:22 schrieb Wolfgang Karall: > Hello Michael, > > On 16-10-02 22:36:00, Michael Biebl wrote: >> The news about systemd crashing when getting a zero sized message >> on the notification socket made the rounds recently. While v215 is >> not directly

Re: Robustify manager_dispatch_notify_fd()

Control: fixed -1 231-9 Am 02.10.2016 um 22:36 schrieb Michael Biebl: > Package: systemd > Version: 215-17+deb8u5 > Severity: important > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: jessie-backport > > The news about systemd crashing when getting a zero

Bug#839607: Robustify manager_dispatch_notify_fd()

would prefer a security upload I'm happy to do that as well. Regards, Michael -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Arch

Re: [SECURITY] [DSA 3661-1] charybdis security update

unsubscribe MPHOFMANN MS MIT Business School dipl.Ing.ETH lic.oec.HSG +41 78 796 4010 <+41787964010> On Tue, Sep 6, 2016 at 10:14 PM, Moritz Muehlenhoff wrote: > -BEGIN PGP SIGNE

Re: httpoxy efforts? (and is it "much" more than just HTTP_PROXY?)

On Wed, Jul 20, 2016 at 03:27:56PM +0200, Christoph Anton Mitterer wrote: If had a small mail conversion with Dominic Scheirlinck (one of the "original" people discovering that issue), and in principle he seemed to confirm that the above could happen, while of course it's less likely than with ht

Re: "Ian Murdock" Death

Dead as in dead. Please take your conspiracy theories elsewhere. On Fri, 2016-07-15 at 16:18 -0700, Kyle Lussier wrote: > CONFIDENTIAL > > Hello Debian / Savatore - > > I am investigating the death of Ian Murdock and also a debian user. > >   * Debian's core MIT distribution may have been compr

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

On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote: BoringSSL is also free software, as long as there are maintainers who are willing to spend time on it, I think it has rights to exist in Debian. Well I have been contributing to Debian for not long, so please point me out my mis

Re: Urgent Card REF#044035

Spam. Ignore it. Original Message From: "pam.castillo67" Sent: Fri Apr 22 09:23:24 GMT+01:00 2016 To: debian-security@lists.debian.org Subject: Re: Urgent Card REF#044035 WHO is Keith Pam is me and that is my email what's up Notice wrote: >Smile Keith > >The Address pam.c

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Tue, Apr 12, 2016 at 08:56:35PM -0300, Henrique de Moraes Holschuh wrote: Then, maybe we should consider a better way to deal with areas where you get only one choice out of geoip? Reach out to the relevant team outlining your issues (e.g., lack of IPv6 connectivity)? Advising people to har

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Tue, Apr 12, 2016 at 04:19:20PM -0300, Henrique de Moraes Holschuh wrote: We don't disclose which mirrors are members of the security.debian.org pool anywhere (that I could find), so we are currently hiding everything behind security.debian.org. This wasn't a problem when a DNS lookup for secu

Re: tracking security issues without CVEs

On Wed, Mar 23, 2016 at 10:59:34AM +0800, Paul Wise wrote: I think Debian needs to go towards the approach of VRDX-SIG and do identifier cross-referencing instead of settling on *one* system for referring to security vulnerabilities. Internally, we would continue to use CVEs and CVE-2016- for

Re: [SECURITY] [DSA 3481-1] glibc security update

On Wed, Feb 17, 2016 at 10:58:01AM +0100, Jan Lühr wrote: Comparing the age (2015-07) and the severity: Can you give some details on the situation? Why was the bug fixed so late? https://sourceware.org/bugzilla/show_bug.cgi?id=18665 Mike Stone

Re: [SECURITY] [DSA 3337-1] gdk-pixbuf security update

een fixed in > version 2.31.1-2+deb8u2. Thanks for taking care of this. From a cursory glance, the patch in 2.31.1-2+deb8u2 seems to be incomplete and is missing the follow-up commit [1]. I'll update the package in unstable. Would be great if you can handle the stable upload. Regards, Micha

Re: Logjam mitigation for Wheezy?

On Tue, Jun 02, 2015 at 02:01:47PM +, Thorsten Glaser wrote: Michael Stone debian.org> writes: You can mitigate it right now by reconfiguring your server to remove DH ciphers from SSLCipherSuite. That’s throwing the baby out with the bathwater and removing the ability to use PFS w

Re: Logjam mitigation for Wheezy?

On Wed, May 20, 2015 at 12:47:35PM -0400, Dan Ritter wrote: Is there any chance of getting Logjam ( https://weakdh.org/ ) mitigation for Wheezy packages? You can mitigate it right now by reconfiguring your server to remove DH ciphers from SSLCipherSuite. Mike Stone -- To UNSUBSCRIBE, email

Re: Should we be alarmed at our state of security support?

John Goerzen wrote: > You know, Mike, *explicit* in my original email was a question of what > help is needed. I was willing to pitch in and help. I may still be. If your goal is to help, then that's really cool. > But how else is someone going to learn that when security-tracker says > "vulner

Re: Should we be alarmed at our state of security support?

On Thu, Feb 19, 2015 at 07:29:29AM -0600, John Goerzen wrote: However, part of what I was trying to figure out here is: do we have a lot of unpatched vulnerabilities in our archive? Yes. Every system (not just debian) has unpatched vulnerabilities. In some cases those vulnerabilities are known

Re: Should we be alarmed at our state of security support?

On Wed, Feb 18, 2015 at 9:11 AM, John Goerzen wrote: > On this machine, it found 472 vulnerabilities. Quite a few of them fit > into the remotely exploitable, high urgency category. Many date back to > last year, some as far back as 2012. I've included a few examples at > the end. I'm not sure

Re: Missing tiff3 patch in security repo

On Wed, Feb 18, 2015 at 12:50 PM, John Goerzen wrote: >> [wheezy] - tiff3 (the changes that [a]ffect the library are just >> hardening, converting uses of sprintf to snprintf. those can be rolled >> into the next tiff3 update, but a separate dsa isn't needed) >> >> > I saw that too, though the bug

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Thu, Feb 05, 2015 at 09:38:11AM +0100, Paul van der Vlis wrote: Op 05-02-15 om 00:54 schreef Holger Levsen: and then finally, sometime later in 2014, security support for oldstable was finally introduced for the first time. There was always a year security support for oldstable (sometimes w

Re: https://wiki.debian.org/LTS/Using => broken?

[I suggested using ftp.us.debian.org rather than http.debian.net because of problems with squeeze-lts on the latter] On Thu, Feb 05, 2015 at 01:57:34PM +0100, Ml Ml wrote: Looks good! Who can report this? :) CC'd the http.debian.net maintainer. Jens, you wrote the original wiki page, is the

Re: https://wiki.debian.org/LTS/Using => broken?

On Thu, Feb 05, 2015 at 01:34:36PM +0100, Ml Ml wrote: can anyone confirm this?: # cat /etc/apt/sources.list deb http://http.debian.net/debian/ squeeze main contrib non-free deb-src http://http.debian.net/debian/ squeeze main contrib non-free deb http://http.debian.net/debian squeeze-lts main

Re: Security EOL within Debian Stable

On Wed, Feb 4, 2015 at 8:09 PM, Stephen Dowdy wrote: > So, if a user installs said package, but fails to notice any EOL DSA > on it, the package gets left in place in a potentially VULNERABLE > state. I.E. if a known exploit comes out, and the package is still > installed, the end-user could get a

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Wed, Feb 4, 2015 at 3:38 PM, Paul van der Vlis wrote: >> The backports team expects backporters to have demonstrated competence >> with the packages that they're planning to upload. Anyone considering >> this should first get involved with the package maintenance teams >> first and help with a

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Mon, Feb 2, 2015 at 11:46 AM, Paul van der Vlis wrote: > I think it's a good idea to do a backport of the build-system after > freeze-time of testing. Then we know what the new build-environment is > for the coming release. > > I can understand that Michael does not have the

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Sun, Feb 1, 2015 at 9:52 PM, Russell Coker wrote: > On Sun, 1 Feb 2015 11:18:43 PM Paul Wise wrote: >> chromium was already being backported to wheezy for security updates, >> the latest versions need newer compilers so we can't backport any >> more. > > Why can't we backport the compilers too?

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Sun, Feb 1, 2015 at 12:15 AM, Chris Frey wrote: > Can someone please point me to the upstream announcement for > dropping gcc 4.7 support? I can't seem to find it, and I'd like > to read up on the details why. The answer is in the previous mail I sent. The short answer is C++11. Best wishes,

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Sat, Jan 31, 2015 at 5:44 PM, Darius Jahandarie wrote: >> Security support for the chromium web browser is now discontinued >> for the stable distribution (wheezy). Chromium upstream stopped >> supporting wheezy's build environment (gcc 4.7, make, etc.), so >> there is no longer any practical w

Re: are unattended updates a good idea?

. Sometimes the package list updates are stuck but mostly recover in the next try. And if something is really wrong you can always login to the server and repair the problem manually. Monitoring these kind of things is really important but is a completely different topic. Michael -- To UNS

Re: test mail.

It failed. On 23/01/2015 18:34, Tom V wrote: De rest kan je allemaal verwijderen -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c33d6d.9020...@gmx.co.uk

Re: [SECURITY] [DSA 3045-1] qemu security update

04.10.2014 23:27, Moritz Muehlenhoff wrote: > - > Debian Security Advisory DSA-3045-1 secur...@debian.org > http://www.debian.org/security/Moritz Muehlenhoff > October 04, 2014

Re: [SECURITY] [DSA 3032-1] bash security update

On Thu, Sep 25, 2014 at 10:54:38AM -0300, Henrique de Moraes Holschuh wrote: I suggest everyone to do a spring cleanup in the login shells for system accounts, and to deploy mitigation. In general it's a good idea to have /bin/sh point to something other than bash. That's the default on curren

Re: Checking for services to be restarted on a default Debian installation

On Wed, Sep 03, 2014 at 11:34:46AM -0700, Jameson Graef Rollins wrote: Is 20MB really a lot? That seems like essentially nothing to me nowadays. I'm in the middle of a 2.2GB upgrade right now. It sure is for people doing minimal installations in a number of contexts. Yeah, it's nothing compa

Re: Checking for services to be restarted on a default Debian installation

On Tue, Sep 02, 2014 at 01:41:05PM -0700, Jameson Graef Rollins wrote: This package is "Priority: optional", and therefore not installed by default. What about just making it "important" or "required"? On my system it pulled in more than 20MB of dependencies. That's a lot to push onto every d

Re: concrete steps for improving apt downloading security and privacy

On Thu, Jul 17, 2014 at 12:55:10PM -0400, Hans-Christoph Steiner wrote: Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. That would be why you'd create a wrapper to faciliate

Re: concrete steps for improving apt downloading security and privacy

On Wed, Jul 16, 2014 at 01:45:36AM +0200, Holger Levsen wrote: AIUI Hans-Christoph wants something else _also_, not instead. And technically I think those signed .debs even exist already, via hashes in signed .changes files. Or am I getting something wrong? Yes you are--what you described is ex

Re: concrete steps for improving apt downloading security and privacy

On Tue, Jul 15, 2014 at 04:24:38PM -0400, Hans-Christoph Steiner wrote: I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pre

Re: concrete steps for improving apt downloading security and privacy

On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: How do you propose managing a distro that mostly needs apt as is, but other times need "Acquire::Check-Valid-Until off;"? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other ti

Re: concrete steps for improving apt downloading security and privacy

On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot o

Re: concrete steps for improving apt downloading security and privacy

On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote: One place that this will help a lot is managing completely offline machines, like machines for running secure build and signing processes. Right now, in order to install a package securely on an offline machine, I have to ma

Re: concrete steps for improving apt downloading security and privacy

On Wed, Jul 09, 2014 at 11:56:43PM -0400, Darius Jahandarie wrote: Someone who is unwilling to click past the first link /now/ may become very willing to continue clicking once they read it. "Debian will not protect you against nation-state adversaries" is a very useful bit of information for ma

Re: concrete steps for improving apt downloading security and privacy

On Wed, Jul 09, 2014 at 10:24:18PM -0600, Kitty Cat wrote: I seem to remember being offered security updates for the kernel, OpenSSL, SSH, etc. where my only option was to download untrusted packages. I would get warning messages from aptitude about installing security updates. Probably a confi

Re: concrete steps for improving apt downloading security and privacy

On Wed, Jul 09, 2014 at 11:11:44PM -0400, Darius Jahandarie wrote: If Tux Q. Debiannewbie doesn't know what adversaries with what powers they are/aren't protected against for their use cases without looking hard and being a security expert, it's hard to make serious claims that Debian is actually

Re: concrete steps for improving apt downloading security and privacy

On Wed, Jul 09, 2014 at 10:15:59PM -0400, Darius Jahandarie wrote: It would be nice for this information to be somewhere more formal than in mailing list archives. Threat models are becoming increasingly important to convey to end users. The mailing list discussion referenced the sources... -

Re: concrete steps for improving apt downloading security and privacy

On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote: For years I have been concerned with MITM attacks on Debian mirrors. We discussed this literally within the past couple of months on this list, at length. Have you read the archives, including the posts about how to establish a trust

Re: concrete steps for improving apt downloading security and privacy

On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote: And you know, the funny thing is that MSIE took to "warning" people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for "secured pages".

Re: Debian mirrors and MITM

On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote: Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. Yes, and MS does similar. The difference is, they own their infrastructure and deb

Re: Debian mirrors and MITM

On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reas

Re: [SECURITY] [DSA 2954-1] dovecot security update

On Tue, Jun 10, 2014 at 02:08:48PM +0200, Matus UHLAR - fantomas wrote: I want to say that debian LTS team are volunteers, but they are not "other" than debian security team, because some of them are in both teams. afaik "other" would imply that people from LTS are not in the debian security tea

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

On Sat, May 31, 2014 at 3:13 PM, Andrew McGlashan wrote: > Google did have OCSP, but they deliberately removed it recently. > > FWIW, Steve Gibson has a very good take on all of this. > > The OCSP server not found issue is rare, in the past the /main/ CA's got > together to discuss the OCSP issue a

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

On Sat, May 31, 2014 at 1:46 PM, Andrew McGlashan wrote: > We may see certificate stapling as an answer, but that won't be enough > if it cannot be certified to /require/ stapling in the cert itself. > There may be other solutions in time. > > You are right in saying that the whole certificate revo

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

On Sat, May 31, 2014 at 12:19 PM, Kurt Roeckx wrote: > This is a manual, I currently see no need to automate it. Does buildd.debian.org provide any information about the up to dateness of its chroots? If this kind of information were available, it would help to determine whether a request for upd

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

On Sat, May 31, 2014 at 11:28 AM, Kurt Roeckx wrote: >> It could be nice if the stable buildds were kept more up to date. >> I've CC'd am...@buildd.debian.org to get their opinion on that. > > I've just updated the chroots. But there is reason to be > concerned that it was build against when there

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

On Sat, May 31, 2014 at 7:44 AM, Andrew McGlashan wrote: > Does Chromium suffer from the Google decision to make use of OCSP > impossible? Therefore, an untrustworthy browser. Basically, the answer is the design of certificate revocation is fundamentally flawed, and Google have their own security

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

On Sat, May 31, 2014 at 5:27 AM, Georgi Naplatanov wrote: > When I choose "About Chromium" menu item it says: > > Version 35.0.1916.114 Built on Debian 7.1, running on Debian 7.5 (270117) > > Is that true that package for AMD64 is built on Debian 7.1? > If yes, is using of this package secure? Yes

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 09:43:47PM +0200, Erwan David wrote: Note that at least debian.org DNS is segned by DNSSEC and DANE is used, which allows to check that the certificate used by a debian.org site is the real one. We're not at the point where that can be relied on in the real world. There

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 10:35:58AM -0700, Jeremie Marguerie wrote: In the end, the PPA can do pretty much whatever it wants from your system and this is scary. This is a hard problem to protect against and the only protection I see is... only install PPAs you can trust. Yup; any pinning mechani

Re: Debian mirrors and MITM

On Sat, May 31, 2014 at 12:46:12AM +1000, Alfie John wrote: Sorry for asking questions. Don't apologize for asking questions, it's perfectly reasonable to do so and you'll find that many people in debian are more than happy to answer questions. Just make sure that you put in enough effort you

Re: Debian mirrors and MITM

On Sat, May 31, 2014 at 12:32:59AM +1000, Alfie John wrote: I'm definitely wanting to engage in serious discussion. I'm an avid Debian user and am wanting to protect its users. This *is* the Debian security mailing list after all right? All I was trying to do is ask questions as to why it is curr

Re: Debian mirrors and MITM

On Sat, May 31, 2014 at 12:11:28AM +1000, Alfie John wrote: On Sat, May 31, 2014, at 12:06 AM, micah anderson wrote: . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out tha

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote: Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be ski

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 11:25:58PM +1000, Alfie John wrote: Well yes, that's something. But serving Debian over HTTPS would prevent the need for this. No, it wouldn't--you'd just have a different set of problems. Given that mirrors are distributed, it would probably be much more likely that y

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote: That's why you verify the initial install media per the link I posted earlier... Oh, and those key fingerprints are on an https page for those who actually trust the CA system. -- To UNSUBSCRIBE, email to debian-security

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 11:13:31PM +1000, Alfie John wrote: As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! That's why you verify the initial install media per t

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: What's stopping the attacker from serving a compromised apt? https://www.debian.org/CD/verify -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptograp

Re: [SECURITY] [DSA 2932-1] qemu security update

19.05.2014 13:47, Giuseppe Iuculano wrote: > - > Debian Security Advisory DSA-2932-1 secur...@debian.org > http://www.debian.org/security/ Giuseppe Iuculano > May 19, 2014

Re: Debians security features in comparison to Ubuntu

> The problem is, that Debian lacks a page similar to: > https://wiki.ubuntu.com/Security/Features > > As you can see, that https://wiki.ubuntu.com/Security/Features page > looks impressive to new users. I guess Debian is losing a few users to > Ubuntu, because Debian does not have such a page. Mo

Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.

On Thu, Jan 2, 2014 at 6:36 PM, Daniel Curtis wrote: > > Hello everyone, > > Michael web site with a statistic I've watching for time to > time. Also Debian Hardening wiki page I studied a couple of > time. > >> There is a lintian check for setuid binaries (...)

Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.

On Wed, Jan 1, 2014 at 12:24 PM, Daniel Curtis wrote: > Hi Moritz, > > 90 percent of the hardening via 'dpkg-buildflags'? That's > a good information. I'd hoped, that the majority of all base > packages and that's security-sensitive will be protected > well. It's really a huge satisfaction. You ca

Re: MIT discovered issue with gcc

On Sat, Nov 30, 2013 at 06:30:50PM -0600, Jordon Bedwell wrote: On Nov 30, 2013 6:29 PM, "Bernhard R. Link" wrote: I think the only answer to those lines is to advise you to not use any programs written in C. I suggest writing everything in Haskell and compiling that to java byte code run in a

  1   2   3   4   5   6   7   8   9   >