Re: [SECURITY] [DSA 3148-1] chromium-browser end of life
On Sat, Jan 31, 2015 at 5:13 PM, Michael Gilbert wrote: > - - > Debian Security Advisory DSA-3148-1 secur...@debian.org > http://www.debian.org/security/ Michael Gilbert > January 31, 2015 http://www.debian.org/security/faq > - - > > Package: chromium-browser > > 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 way to continue building security > updates. How unfortunate. Was this due to the chromium team not being aware of this consequence? What can we do to make it easier and more compelling for upstreams to continue supporting popular build environments needed for keeping the internet safe? -- Darius Jahandarie -- 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/CAFANWtUzZ76ja=+1ieGEX80ZZgQTemUwq8EJKNwXP_RvY+W=g...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 9, 2014 at 11:23 PM, Michael Stone wrote: > I frankly find it hard to believe that someone who is unwilling to click > past the first link when researching actually cares much about any kind of > writeup of threat models. I'll make it simple: if you're completely > unsophisticated and worried about a government hijacking your linux > distribution to spy on you, there's nothing debian can do to help you. If > you're low profile and uninteresting, the government doesn't care about you. > If you're actually being targeted by well funded and sophisticated > adversaries, they're going to get you unless you put a heck of a lot more > effort in than clicking on the first link. 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 many non-technical activists, which often leads to the questions: * "Why?" (what powers can they use to subvert existing protections?) * "What /does/ protect you?" (what new protections need I put in place such that those powers cannot subvert them?) It would be lovely to have the answers nearby. -- Darius Jahandarie -- 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/CAFANWtVc1URqiCiOBYBpxEDUyWh8Qn0sf_=esqt3x9bu3u_...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 9, 2014 at 10:53 PM, Michael Stone wrote: > 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... What I mean by "more formal" can be approximated by "discoverable by searching 'debian security' on Google and clicking on the first link". 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 protecting its users. (Halting the endless discussion loops on debian-security@ is just a nice side effect of fixing the actual problem.) -- Darius Jahandarie -- 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/cafanwtvwpq8qxoj+yyn_nhpxymq4hoazn58oo5etcquzoke...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 9, 2014 at 10:11 PM, Michael Stone wrote: > 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 path to the ISOs? 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. -- Darius Jahandarie -- 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/cafanwtwqzfcvnb9ozm1wmccmzytvpjbtot4om9w+bf9anpc...@mail.gmail.com
Re: Check for revocation certificates before running apt-get?
On Sun, Dec 15, 2013 at 12:17 AM, Paul Wise wrote: > That would probably be fine for most Debian users but at that point I > remembered that the Riseup OpenGPG best practices document has > something to say about keyring refreshes; that keyring refreshes > should happen using parcimonie to make correlation attacks harder. This thread is probably not the most apropos place to bring this up, but I've found parcimonie to be an terribly over-complex implementation of the (good) design document that they wrote. It requires pulling in dozens of perl modules, including GTK bindings (?). It worries me that it's starting to become the defacto tool for keeping a keyring up-to-date, because security is one of the places where minimalism really matters. -- Darius Jahandarie -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafanwtv2tmv-rsuidk1wtdp9vghodzenk6po-tm2whtt2ae...@mail.gmail.com
Re: MIT discovered issue with gcc
On Sat, Nov 23, 2013 at 1:16 PM, Mark Haase wrote: > Anyway, I don't see what this has to do with Debian. It's an interesting > paper, but Debian can't find and fix all upstream bugs, nor do I think most > users would be happy if suddenly everything was compiled without any > optimizations. Although Debian *developers* can't find and fix all upstream bugs, the Debian project, as the funnel between code and users, provides an interesting location to perform this sort of automated static analysis on all source code flowing through it, and present that information to both the package maintainers and users of the packages. -- Darius Jahandarie -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafanwtw2r+2w0e3ewvcmse-zcvbxfgugs6sp+ppu9q6gv7x...@mail.gmail.com
