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

[Michael Gilbert]

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?

As mentioned already it was discussed [0], and the release team seemed
willing to consider the idea.  I simply didn't have the time or
motivation myself to do it.

If there were someone willing to maintain it, and work through the
process, it could thus theoretically be done.

Best wishes,
Mike

[0] http://bugs.debian.org/763278


-- 
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/CANTw=MMoaV7za34PCz35cj5nv9NJuo=sW7K=l-dozgb7b0j...@mail.gmail.com

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

[Paul Wise]

On Mon, Feb 2, 2015 at 10:52 AM, Russell Coker wrote:

> Why can't we backport the compilers too?

I think you meant to send this question to t...@security.debian.org
and debian-rele...@lists.debian.org.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/CAKTje6E3MydTFooeBwEoG78tiiuy-ZSo75XBvF4VTGt=8tp...@mail.gmail.com

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

[Russell Coker]

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?


-- 
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/201502020252.36485.russ...@coker.com.au

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

[Paul Wise]

On Mon, Feb 2, 2015 at 3:14 AM, Pavlos K. Ponos wrote:

> Since the latest gcc version for Wheezy is the 4.7 and Chromium "moves" to 
> 4.8, what shall we do?

Follow the advice in DSA-3148-1: upgrade to jessie or switch to the
iceweasel web browser.

> Till the next stable release (Jessie), are we vulnerable to security issues?

If you continue to use chromium from Debian wheezy yes.

> this goes against the "stable philosophy" of Debian, at least in its stable 
> version.

The policy for Debian stable has limits based in the reality of
software development.

> So, what are the alternatives in our case?

Upgrade to jessie or switch to another web browser.

> Maybe it sound a "stupid" question but what about if we keep track of 
> backports and proposed updates in Wheezy?

chromium was already being backported to wheezy for security updates,
the latest versions need newer compilers so we can't backport any
more.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/caktje6fpyxvtvwuqmcwcprmnsjqj2izwmplzjlqzcma85om...@mail.gmail.com

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

[Pavlos K. Ponos]

Hello,

Since the latest gcc version for Wheezy is the 4.7 and Chromium "moves" 
to 4.8, what shall we do? Till the next stable release (Jessie), are we 
vulnerable to security issues?
As mentioned before, we can build environments to support all the 
upstream features but this goes against the "stable philosophy" of 
Debian, at least in its stable version.


So, what are the alternatives in our case?
Maybe it sound a "stupid" question but what about if we keep track of 
backports and proposed updates in Wheezy?


Thanks in advance for your feedback.
Regards,
Pavlos

*Pavlos K. Ponos*
View Pavlos K. Ponos's profile on LinkedIn 


On 02/01/2015 01:02 AM, Michael Gilbert wrote:

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 way to continue building security
updates.

How unfortunate.

Was this due to the chromium team not being aware of this consequence?

No, it was a conscious decision (they considered Debian specifically):
http://phajdan-jr.blogspot.com/2014/08/can-your-distro-compile-chromium.html


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?

Another option is to update build environments to support all of the
features upstreams want to use, but that doesn't fit well with
Debian's long-term stable model.  I spent time looking into that, but
with jessie releasing soon (with a sufficient build environment), I
didn't have the motivation or time to do that.

Best wishes,
Mike

Re: are unattended updates a good idea?

[ge...@riseup.net]

On 15-01-31 09:58:39, Ml Ml wrote:
> i have got about 50 Debian 6+7 Servers. They are doing all kind of
> things like Webserver, Mailserver, DNS, etc…
> 
> I am using apticron to keep track of the updates, but i seem to use
> more and more time updating the hosts.
>
> [...]
>
> Is anyone else facing the same problem? What are your experiences
> doing (blind) automatic security updates.
> 
> Or are you maybe using something completly diffrent like puppet?
> 
> Whats your practical experience with lots of servers?  (i am not
> interested in theoretical advises :-P )

I've not using unattended upgrades or stuff like this, but apt-dater
[1]: "apt-dater provides an ncurses frontend for managing package
updates on a large number of remote hosts using SSH. It supports
Debian-based managed hosts as well as rug (e.g. openSUSE) and yum (e.g.
CentOS) based systems."

It's a great tool, which I can fully recommend, using it to upgrade
around 200 machines.

A similar tool is UPDIAN, with which I've got no experience at all, and
it's not packaged for Debian (yet?), but still, it may be worth a look.

Cheers,
Georg


[1] https://packages.debian.org/wheezy/apt-dater
[2] https://github.com/robhost/UPDIAN


signature.asc
Description: Digital signature

Re: are unattended updates a good idea?

[Will Aoki]

On Sat, Jan 31, 2015 at 09:58:39AM +0100, Ml Ml wrote:
> Is anyone else facing the same problem? What are your experiences
> doing (blind) automatic security updates.

I've done automatic updates for Debian under cfengine control for nine
years and Ubuntu for perhaps one and a half. I started with a small
number of systems and gradually expanded it out until it includes most
servers. I can't think of any incidents where this has caused serious
problems, but I still update a handful of systems exclusively by hand.

The major problems, limitations and warnings I'm aware of are:

- In /etc/apt/sources.list it's very important to specify the release by
  name: you should use e.g. 'wheezy' instead of 'stable'. Otherwise you
  risk breaking your systems when jessie is released.

- It's important to have an easy way to turn off automatic updates on a
  particular system so that you can do maintenance work, and it's
  important to have an easy way to turn off automatic updates globally
  if you need to.

- It's probably a good idea to have some way of delaying updates to your
  critical production systems until you've checked them out on your test
  and less-critical production systems.

- My scripts do not reboot the system or restart any services that APT
  doesn't. This means I have to restart services or systems manually for
  library and kernel updates. I have Nagios check for systems that
  require a reboot and I restart them during a maintenance window.

- In the past, certain upgrade failures have broken the kernel or
  bootloader badly enough to leave systems unbootable without manual
  attention. If memory serves, this was most common on squeeze or lenny
  but hasn't happened frequently on wheezy. It's important to review the
  transcript of the upgrade session before you reboot.

- Starting last spring, certain unattended upgrades (possibly things
  that trigger man-db's maintainerscripts?) began to fail if /bin/sh is
  dash, but not if it's bash. My hunch is that this might be related to
  not having a controlling TTY attached when apt-get is run by cfagent.

  I don't have enough information at this point to be confident it's not
  related to the way I'm invoking it or to file a useful bug report
  against anything. I haven't worked on it recently, but I have notes
  saying it might be related to bug #439763.

I use the following, but there are likely better ways to do it nowadays:

- Before doing anything else:
  /usr/bin/apt-get update -qq --trivial-only

- To install all available updates, security and otherwise:
  /bin/sh -c 'DEBIAN_FRONTEND=noninteractive DEBCONF_REDIR= /usr/bin/apt-get 
-o="DPkg::Options=--force-confdef,confold" upgrade -qq -y' ifelapsed=65

- To install a particular package (%s to be replaced with the name):
  /bin/sh -c 'DEBIAN_FRONTEND=noninteractive /usr/bin/apt-get 
-o="DPkg::Options::=--force-confdef,confold" install -qq -y %s'

- To remove a packages (%s to be replaced with the name):
  /bin/sh -c 'DEBIAN_FRONTEND=noninteractive /usr/bin/apt-get remove -qq -y %s'


On Sat, Jan 31, 2015 at 12:53:32PM +0100, Michael Zoet wrote:
> You can do updates with Puppet (or every other configuration
> management tool you like) but using it for updating the whole system
> is not the way I would go. You would need to create a complete list
> of installed packages on the server and keep this up2date in Puppet.

This is more or less the approach I take for updating MacOS X with
softwareupdate(8), as it has fewer packages and a worse history of
updates breaking things than Debian and Ubuntu.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924


-- 
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/20150201172924.ga13...@umnh.utah.edu

Re: Debian Live CD - unsecured ssh open by default

[John Goerzen]

Great news, thanks!

On 01/31/2015 07:01 PM, Evgeny Kapun wrote:
> This should be fixed in the latest version. See 
> https://bugs.debian.org/741678.
>
> On 01.02.2015 03:09, John Goerzen wrote:
>> Hello,
>>
>> A friend of mine pointed out to me recently that the Debian Live CD has
>> ssh open to the network by default, and the "user" account -- which has
>> passwordless sudo to root privileges -- has a password that is
>> well-known and easily found via Google.  This poses some nasty surprises
>> for people that might be using it to repair systems on their LAN, and
>> even worse surprises for people that might install the Live CD image to
>> their system.
>>
>> I have seen a few mentions of this online, but it doesn't seem that
>> people are thinking of it as a security risk.  What is the best way to
>> get this fixed?
>>
>> Thanks!
>>
>> -- John
>>
>>
>


-- 
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/54ce1385.40...@complete.org