On Mon, 2012-02-20 at 19:50 -0500, Michael Gilbert wrote:
> But anyway, I think to get anywhere you'll need to help get Debian
> policy 2.2.1 clarified for these kind of conditions. Then you'll be
> able to submit bugs with appropriate RC severity so they'll have to be
> handled.
Phew,.. changing
On Tue, 2012-02-21 at 16:59 -0600, Gunnar Wolf wrote:
> Sadly, I think this is more propaganda and wishful thinking than
> reality. And if I'm going to badmouth somebody, I'll badmouth myself.
I guess you're right, that for large software it's difficult to
impossible for the maintainer to really f
I demand that Toni Mueller may or may not have written...
> On 02/18/2012 11:48 AM, Thomas Koch wrote:
>> What about a debhelper script that receives an URL (or set of mirror
>> URLs) and a SHA1 and does the download and check?
> If you're going this way, try to peek at the *BSD's ports systems,
On Tue, 21 Feb 2012, Gunnar Wolf wrote:
> Henrique de Moraes Holschuh dijo [Sat, Feb 18, 2012 at 10:46:50AM -0200]:
> > Good packaging developers go to great lengths to be sure they are not
> > going to distribute anything trojaned. This takes a lot of work, and
> > often requires very goot workin
Henrique de Moraes Holschuh dijo [Sat, Feb 18, 2012 at 10:46:50AM -0200]:
> Good packaging developers go to great lengths to be sure they are not
> going to distribute anything trojaned. This takes a lot of work, and
> often requires very goot working relationship with upstream to the point
> of g
On 02/18/2012 11:48 AM, Thomas Koch wrote:
> What about a debhelper script that receives an URL (or set of mirror URLs)
> and
> a SHA1 and does the download and check?
If you're going this way, try to peek at the *BSD's ports systems,
specifically their 'distinfo' files. SHA1 is not enough, imho
On Fri, Feb 17, 2012 at 11:09 PM, Christoph Anton Mitterer wrote:
> For many of those I've reported bugs (and I'm sure I didn't found a lot of
> them, and I'm further sure
> that new cases were introduced).
> Some where closed, some where just ignored or denied.
Fortunately, this is rather uncommo
On Mon, 2012-02-20 at 09:56 +, Philipp Kern wrote:
> Well, the rationale is documented in #333552 (which is linked to by the
> changelog).
I dropped some words on "rationale" to the aforementioned bug,...
> AIUI it doesn't matter because it's just about randomizing
> unused parts of the packe
On 2012-02-20, Christoph Anton Mitterer wrote:
> 2) Well I really feel bad now, having to point my finger at the Nagios
> Maintainers as they really do a good job, but this just shocked me:
> Bug #660585.
>
> Well as I describe in the bug, it is practically (at the moment) of no
> relevance as SSL
On Sat, Feb 18, 2012 at 06:09:37AM +0200, Christoph Anton Mitterer wrote:
> - packages that are just wrapper packages, download something from
> somewhere without doing any
> hashsum checks at all
How many in main?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subje
Hey.
Just by now,... two additional cases of security problems crossed my
mind.
Though not related to our package signing, they originate to some extent
in the same problem as everything that was discussed in this thread
before:
Insufficient "feeling" for security [by maintainers].
1) Silent mod
On Sat, Feb 18, 2012 at 04:42:38PM -0200, Henrique de Moraes Holschuh wrote:
> > Against what? The source is only downloaded from upstream once per
> > upstream release, what is there to check against?
>
> Upstream VCS, previous releases (when the diff is small enough), request
> that upstream pub
On Sat, 18 Feb 2012, Philip Hands wrote:
> On Sat, 18 Feb 2012 15:49:30 +, Neil Williams wrote:
> > On Sat, 18 Feb 2012 16:25:20 +0200
> > Christoph Anton Mitterer wrote:
> > > Am 18.02.2012 14:40, schrieb Neil Williams:
> > > >> I think as a start it should be made a policy that any "wrapper
On Sat, 18 Feb 2012, Neil Williams wrote:
> On Sat, 18 Feb 2012 16:25:20 +0200
> Christoph Anton Mitterer wrote:
> > Am 18.02.2012 14:40, schrieb Neil Williams:
> > >> I think as a start it should be made a policy that any "wrapper"
> > >> package that
> > >> downloads code from the net must at l
On 02/18/2012 09:30 PM, Josselin Mouette wrote:
> Plugin integrity is
> guaranteed by SSL, and extensions have been checked before being put on
> the website.
>
I feel much much safer now that I know that my plugin downloads
are protected by Diginotar ! :)
Thomas
--
To UNSUBSCRIBE, email to
On 02/18/2012 08:40 PM, Neil Williams wrote:
> On Sat, 18 Feb 2012 11:48:27 +0100
> Thomas Koch wrote:
>
>
>> I think as a start it should be made a policy that any "wrapper" package
>> that
>> downloads code from the net must at least do a strong checksum check on the
>> downloaded code.
>>
On Sat, Feb 18, 2012 at 04:31:19PM +0100, Ansgar Burchardt wrote:
> Jakub Wilk writes:
> > * Ansgar Burchardt , 2012-02-18, 14:14:
> >>>Could you point us to those which were ignored or denied?
> >>At least pbuilder still disables secure APT by default, see #579028.
> >
> > The bug is closed. Am I
Am 18.02.2012 18:45, schrieb Philip Hands:
He's talking about stuff like flash-nonfree (or whatever) where we
ship
a wrapper that wgets the actual tarball for you from the distributor,
and checks the checksum of whatever it ends up with.
Yes!
(perhaps if paranoid do the
download from elsewher
Am 18.02.2012 19:03, schrieb brian m. carlson:
On Sat, Feb 18, 2012 at 11:48:27AM +0100, Thomas Koch wrote:
What about a debhelper script that receives an URL (or set of mirror
URLs) and a SHA1 and does the download and check?
Please use something stronger than SHA-1. SHA-1 has some weaknesses
Am 18.02.2012 16:18, schrieb Jakub Wilk:
The bug is closed. Am I missing something?
But anyway, this is saddening. Hundreds (? - wild guess) of
developers have been building their packages in insecure environment,
yet pbuilder maintainer and a member of Security Team believe that it
was a featur
On Sat, Feb 18, 2012 at 11:48:27AM +0100, Thomas Koch wrote:
> What about a debhelper script that receives an URL (or set of mirror
> URLs) and a SHA1 and does the download and check?
Please use something stronger than SHA-1. SHA-1 has some weaknesses and
something like SHA-256 or SHA-512 should
On Sat, 18 Feb 2012 15:49:30 +, Neil Williams wrote:
> On Sat, 18 Feb 2012 16:25:20 +0200
> Christoph Anton Mitterer wrote:
>
> > Am 18.02.2012 14:40, schrieb Neil Williams:
> > >> I think as a start it should be made a policy that any "wrapper"
> > >> package that
> > >> downloads code fro
On Sat, 18 Feb 2012 15:59:38 +0200
Christoph Anton Mitterer wrote:
> Am 18.02.2012 10:11, schrieb Teus Benschop:
> > To put things in perspective, I just wonder how strong this
> > 'fortress'
> > really is, and whether this strength is only in our perception or
> > whether it is real. Let me giv
On Sat, 18 Feb 2012 16:25:20 +0200
Christoph Anton Mitterer wrote:
> Am 18.02.2012 14:40, schrieb Neil Williams:
> >> I think as a start it should be made a policy that any "wrapper"
> >> package that
> >> downloads code from the net must at least do a strong checksum check
> >> on the
> >> dow
Jakub Wilk writes:
> * Ansgar Burchardt , 2012-02-18, 14:14:
>>>Could you point us to those which were ignored or denied?
>>At least pbuilder still disables secure APT by default, see #579028.
>
> The bug is closed. Am I missing something?
pbuilder was changed to pass the --keyring argument to de
* Christoph Anton Mitterer , 2012-02-18, 16:19:
Take the non-free flash as example... (yeah I know it's non-free and
not officially sec-supported)..
Even if it would use some SHA512 sums (hardcoded into the package) to
verify the download (I don't know whether it does),.. the update
mechanism i
Am 18.02.2012 15:30, schrieb Josselin Mouette:
Personally I decided to use GNOME-fallback, but via the
meta-packages I
still got the GNOME shell... today
I've noticed that it silently installs an extension, which (I can
only
assume this by the little
description) does some software installatio
Am 18.02.2012 14:40, schrieb Neil Williams:
I think as a start it should be made a policy that any "wrapper"
package that
downloads code from the net must at least do a strong checksum check
on the
downloaded code.
Not possible to enforce as a 'MUST' because, by definition,
third-party
websit
Am 18.02.2012 14:34, schrieb Neil Williams:
>- packages that eventually run some code which was downloaded
>unsecured.
>debootstrap used to be like that, pbuilder, and some others
Only a bug if this happens by default.
It is perfectly acceptable to support an option to disable SecureApt
-
ju
Am 18.02.2012 13:32, schrieb Jakub Wilk:
I'll add to the list:
- Packages that download and run untrusted code at build time.
May I add a similar case...
Take the non-free flash as example... (yeah I know it's non-free and
not officially sec-supported)..
Even if it would use some SHA512 sums (h
* Ansgar Burchardt , 2012-02-18, 14:14:
Could you point us to those which were ignored or denied?
At least pbuilder still disables secure APT by default, see #579028.
The bug is closed. Am I missing something?
But anyway, this is saddening. Hundreds (? - wild guess) of developers
have been b
Am 18.02.2012 13:14, schrieb Benjamin Drung:
This is no problem for us, because the malware was distributed on
some
untrustworthy websites. We, as packagers, get the code directly from
the
Videolan project.
So you meet them once in person and exchanged some kind of PKI/shared
secret etc?
Tha
Am 18.02.2012 10:11, schrieb Teus Benschop:
To put things in perspective, I just wonder how strong this
'fortress'
really is, and whether this strength is only in our perception or
whether it is real. Let me give just one example: A developer
downloads
a tarball from an upstream source, configu
Jakub Wilk writes:
> Could you point us to those which were ignored or denied?
At least pbuilder still disables secure APT by default, see #579028.
Regards
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis
Le samedi 18 février 2012 à 06:09 +0200, Christoph Anton Mitterer a
écrit :
> Personally I decided to use GNOME-fallback, but via the meta-packages I
> still got the GNOME shell... today
> I've noticed that it silently installs an extension, which (I can only
> assume this by the little
> descri
On Sat, 18 Feb 2012, Teus Benschop wrote:
> To put things in perspective, I just wonder how strong this 'fortress'
> really is, and whether this strength is only in our perception or
> whether it is real. Let me give just one example: A developer downloads
> a tarball from an upstream source, confi
On Sat, 18 Feb 2012 11:48:27 +0100
Thomas Koch wrote:
> I think as a start it should be made a policy that any "wrapper" package that
> downloads code from the net must at least do a strong checksum check on the
> downloaded code.
Not possible to enforce as a 'MUST' because, by definition, thi
On Sat, 18 Feb 2012 12:32:14 +0100
Jakub Wilk wrote:
> * Christoph Anton Mitterer , 2012-02-18, 06:09:
> >I've decided that I think it's important to CC this d-d:
> >Debian has a good system of securing packages and making sure that only
> >signed stuff comes to the user.
> >Over time I've seen
* Christoph Anton Mitterer , 2012-02-18, 06:09:
I've decided that I think it's important to CC this d-d:
Debian has a good system of securing packages and making sure that only
signed stuff comes to the user.
Over time I've seen many holes in this:
- packages that are just wrapper packages, dow
Am Samstag, den 18.02.2012, 11:48 +0100 schrieb Thomas Koch:
> July 2011 VLC suffers from Companies spreading Malware bundled with VLC
This is no problem for us, because the malware was distributed on some
untrustworthy websites. We, as packagers, get the code directly from the
Videolan projec
Christoph Anton Mitterer:
> Hey.
>
> I've decided that I think it's important to CC this d-d:
> Debian has a good system of securing packages and making sure that only
> signed stuff comes to the user.
> Over time I've seen many holes in this:
> - packages that are just wrapper packages, download
To put things in perspective, I just wonder how strong this 'fortress'
really is, and whether this strength is only in our perception or
whether it is real. Let me give just one example: A developer downloads
a tarball from an upstream source, configures it, and does make install,
yet has not even
Hey.
I've decided that I think it's important to CC this d-d:
Debian has a good system of securing packages and making sure that only
signed stuff comes to the user.
Over time I've seen many holes in this:
- packages that are just wrapper packages, download something from
somewhere without doi
43 matches
Mail list logo
