René Mayrhofer wrote:
> On 2014-09-25 06:24, Hans-Christoph Steiner wrote:
>>
>> W. Martin Borgert wrote:
>>> On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
* the signature files sign the package contents, not the hash of
whole .deb file (i.e. control.tar.gz and data.tar.gz).
>>>
On 2014-09-25 06:24, Hans-Christoph Steiner wrote:
>
> W. Martin Borgert wrote:
>> On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
>>> * the signature files sign the package contents, not the hash of
>>> whole .deb file (i.e. control.tar.gz and data.tar.gz).
>> So preinst and friends would not
On Sunday 21 September 2014 21:13:50, Richard van den Berg wrote:
> Package formats like apk and jar avoid this chicken and egg problem
> by hashing the files inside a package, and storing those hashes in
> a manifest file. Signatures only sign the manifest file. The
> manifest itself and the signa
W. Martin Borgert wrote:
> On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
>> * the signature files sign the package contents, not the hash of
>> whole .deb file (i.e. control.tar.gz and data.tar.gz).
>
> So preinst and friends would not be signed? Sounds dangerous to me.
All package conte
On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
> * the signature files sign the package contents, not the hash of
> whole .deb file (i.e. control.tar.gz and data.tar.gz).
So preinst and friends would not be signed? Sounds dangerous to me.
--
To UNSUBSCRIBE, email to debian-security-requ..
Daniel Kahn Gillmor wrote:
> Thanks for the discussion, Hans.
>
> On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote:
>> Packages should not be accepted into any official repo, sid included, without
>> some verification builds. A .deb should remain unchanged once it is accepted
>> into any of
Daniel Kahn Gillmor wrote:
> On 09/22/2014 04:06 PM, Hans-Christoph Steiner wrote:
>> I think we're starting to nail down the moving parts here, so I want to
>> outline that so we can find out the parts where we agree and where we
>> disagree.
>>
>> * I hope we can all agree that the package its
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 (preins
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 definitel
Am 22.09.14 um 01:52 schrieb Paul Wise:
On Mon, Sep 22, 2014 at 2:04 AM, Elmar Stellnberger wrote:
A package with some new signatures added is no more the old package.
That is exactly what we do *not* want for reproducible builds.
It should have a different checksum and be made available
On Mon, Sep 22, 2014 at 7:52 AM, Paul Wise wrote:
> Reproducible builds and independent verification of those builds by
> multiple parties...
sigh... is an essential feature for any operating system in today's
security climate.
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE
On Mon, Sep 22, 2014 at 2:04 AM, Elmar Stellnberger wrote:
>A package with some new signatures added is no more the old package.
That is exactly what we do *not* want for reproducible builds.
> It should have a different checksum and be made available again for update.
The Debian archive do
On 2014-09-21 21:13, Richard van den Berg wrote:
> Package formats like apk and jar avoid this chicken and egg problem by
> hashing the files inside a package, and storing those hashes in a manifest
> file.
Is there a "chicken and egg problem"? Only if one insists on embedding
the signatures in
On 21 sep. 2014, at 20:29, W. Martin Borgert wrote:
> If a package would change by adding another signature, then this
> would invalidate previous signatures.
Package formats like apk and jar avoid this chicken and egg problem by hashing
the files inside a package, and storing those hashes in a
On 2014-09-21 20:04, Elmar Stellnberger wrote:
>A package with some new signatures added is no more the old package.
> It should have a different checksum and be made available again for update.
> Perhaps someone wants to install the package not before certain signatures
> have been added.
If
A package with some new signatures added is no more the old package.
It should have a different checksum and be made available again for update.
Perhaps someone wants to install the package not before certain signatures
have been added.
Your thought experiment would this way of course require
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 t
Am 19.09.14 um 06:34 schrieb Paul Wise:
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
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 th
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 signe
Holger Levsen wrote:
> Hi Hans,
>
> On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote:
>> What I'm talking about already exists in Debian, but is rarely used.
>> dpkg-sig creates a signature that is embedded in the .deb file. So that
>> means no matter how the .deb file got onto a syste
Hi Hans,
On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote:
> What I'm talking about already exists in Debian, but is rarely used.
> dpkg-sig creates a signature that is embedded in the .deb file. So that
> means no matter how the .deb file got onto a system, that signature can be
> verif
On Thu, Jul 17, 2014 at 12:55:10PM -0400, Hans-Christoph Steiner wrote:
Not without modifying the apt config. The point here is to have a working
system that is tested and audited, rather than just a set of instructions or
recommendations.
That would be why you'd create a wrapper to faciliate
On 07/17/2014 08:20 AM, Joel Rees wrote:
> A little context?
>
> On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner wrote:
>> [...]
>> * TAILS is a Debian-based live CD
>> * the core system image by definition cannot be modified (live CD)
>> * it has a feature for persistent storage of fil
A little context?
On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner wrote:
>[...]
> * TAILS is a Debian-based live CD
> * the core system image by definition cannot be modified (live CD)
> * it has a feature for persistent storage of files on a USB thumb drive
What happens when you put you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 16-07-14 18:26, Hans-Christoph Steiner wrote:
>
>
> On 07/16/2014 08:06 AM, Holger Levsen wrote:
>> Hi,
>>
>> On Mittwoch, 16. Juli 2014, Michael Stone wrote:
>>> Yes you are--what you described is exactly how the Release
>>> files work.
>>
>>
On 07/16/2014 08:06 AM, Holger Levsen wrote:
> Hi,
>
> On Mittwoch, 16. Juli 2014, Michael Stone wrote:
>> Yes you are--what you described is exactly how the Release files work.
>
> Well, there are (many) other .debs on the net which are not part of our
> releases, so it still seems to me that
Hi,
On Mittwoch, 16. Juli 2014, Michael Stone wrote:
> Yes you are--what you described is exactly how the Release files work.
Well, there are (many) other .debs on the net which are not part of our
releases, so it still seems to me that making .changes files accessable in
standardized ways coul
On Wed, Jul 16, 2014 at 01:45:36AM +0200, Holger Levsen wrote:
AIUI Hans-Christoph wants something else _also_, not instead. And technically
I think those signed .debs even exist already, via hashes in signed .changes
files. Or am I getting something wrong?
Yes you are--what you described is ex
Hi,
On Dienstag, 15. Juli 2014, Michael Stone wrote:
> Except that you haven't addressed *at all* why the current mechanism is
> insufficient, except that you don't like it and want to do something
> else instead.
AIUI Hans-Christoph wants something else _also_, not instead. And technically
I t
On Tue, Jul 15, 2014 at 04:24:38PM -0400, Hans-Christoph Steiner wrote:
I'm not saying that adding .deb signature validation to `dpkg -i` would be
trivial and without risk. But the idea of validating signed package files on
install is hardly revolutionary or even novel any more. Indeed it is pre
On 07/15/2014 02:11 PM, Michael Stone wrote:
> On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote:
>> How do you propose managing a distro that mostly needs apt as is, but other
>> times need "Acquire::Check-Valid-Until off;"? In other words, how would you
>> manage a distro
On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote:
How do you propose managing a distro that mostly needs apt as is, but other
times need "Acquire::Check-Valid-Until off;"? In other words, how would you
manage a distro that sometimes uses apt as it was designed, and other ti
On 07/14/2014 01:57 PM, Michael Stone wrote:
> On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote:
>>> Or, you could make use of the Check-Valid-Until and Min-ValidTime options in
>>> apt.conf. There's a reason things are done the way they are, and you
>>> probably
>>> aren't
On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote:
Or, you could make use of the Check-Valid-Until and Min-ValidTime options in
apt.conf. There's a reason things are done the way they are, and you probably
aren't going to find a lot of interest in getting people to do a lot o
On 07/14/2014 01:12 PM, Michael Stone wrote:
> On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote:
>> One place that this will help a lot is managing completely offline machines,
>> like machines for running secure build and signing processes. Right now, in
>> order to instal
On 07/14/2014 12:59 PM, Paul Wise wrote:
> On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote:
>
>> I'd like to contribute to this effort
>
> First thing is to get #733029 fixed, which involves disabling signing
> by default (signing should be done after testing not before) and
> ad
On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote:
One place that this will help a lot is managing completely offline machines,
like machines for running secure build and signing processes. Right now, in
order to install a package securely on an offline machine, I have to ma
On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote:
> I'd like to contribute to this effort
First thing is to get #733029 fixed, which involves disabling signing
by default (signing should be done after testing not before) and
adding a signing tool to dpkg-dev. Then debsign/debuild ne
On 07/14/2014 12:31 PM, Paul Wise wrote:
> On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote:
>
>> I agree that .deb packages should be individually signed
> ...
>> This has been discussed in the past. I really think it is just a
>> matter of someone doing the work.
>
> The work h
On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote:
> I agree that .deb packages should be individually signed
...
> This has been discussed in the past. I really think it is just a
> matter of someone doing the work.
The work has been done many years ago and has been in the archive
I agree that .deb packages should be individually signed, but I don't think
that the current apt system is vulnerable to package corruption.
Having a signature in the .deb. would make things a lot more flexible in
terms of distribution because a .deb could be verified no matter how it ends
up on
On Sun, Jul 13, 2014 at 1:28 PM, Noah Meyerhans wrote:
> On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote:
>> MD5 has been broken for a small number of applications. Its status is
>> questionable for the rest, but if we want to help break it completely,
>> let's get all the distros that i
Yes, I also think it is a pretty shame that we can not download the
sha256/512sums
from a sever secured by https + DNSSEC/DANE. At least the master mirror
cdimage.debian.org needs to provide a secure connection for downloading
checksums and the *.jigdo and *.template files. Moreover I would appr
On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote:
> MD5 has been broken for a small number of applications. Its status is
> questionable for the rest, but if we want to help break it completely,
> let's get all the distros that insist on still using MD5 to use it,
> not just for signing, b
On Sun, Jul 13, 2014 at 5:04 AM, Jann Horn wrote:
> On Mon, Jul 07, 2014 at 08:09:14PM +0900, Joel Rees wrote:
>> But again, that's only half the story. When you send a kernel image
>> encrypted, they have the plaintext and the crypt, and the thing is
>> large and hard. This is the kind of data th
On Mon, Jul 07, 2014 at 08:09:14PM +0900, Joel Rees wrote:
> But again, that's only half the story. When you send a kernel image
> encrypted, they have the plaintext and the crypt, and the thing is
> large and hard. This is the kind of data that can be used to
> completely break an entire encryptio
Am 11.07.2014 um 02:55 schrieb Eirik Schwenke:
> On 10 July 2014 18:07:59 CEST, Elmar Stellnberger wrote:
>
>> In order to prevent unsuspecting users from downloading a compromised
>> version of Debian I wanna propose the following:
>>
>> * promote the inclusion of Debian-public-keys in any fr
On 10 July 2014 18:07:59 CEST, Elmar Stellnberger wrote:
>In order to prevent unsuspecting users from downloading a compromised
>version of Debian I wanna propose the following:
>
>* promote the inclusion of Debian-public-keys in any free live CD sold
>with magazines and books:
I believe there i
On Thu, Jul 10, 2014 at 9:29 AM, Kitty Cat wrote:
> For years I have been concerned with MITM attacks on Debian mirrors.
>
> [...]
Hate to trivialize your concerns, but the Debian organization cannot
control the mirrors people provide it and remain Debian.
You have to remember that when even pro
Now; I believe there are several things Debian could do to improve security.
In order to prevent unsuspecting users from downloading a compromised version
of Debian I wanna propose the following:
* promote the inclusion of Debian-public-keys in any free live CD sold with
magazines and books:
On Wed, Jul 09, 2014 at 11:56:43PM -0400, Darius Jahandarie wrote:
Someone who is unwilling to click past the first link /now/ may become
very willing to continue clicking once they read it.
"Debian will not protect you against nation-state adversaries" is a
very useful bit of information for ma
On Wed, Jul 09, 2014 at 10:24:18PM -0600, Kitty Cat wrote:
I seem to remember being offered security updates for the kernel, OpenSSL, SSH,
etc. where my only option was to download
untrusted packages. I would get warning messages from aptitude about installing
security updates.
Probably a confi
2014-07-07 12:13 GMT-08:00 Andrea Zwirner :
> Can you proof it?
>
> Or maybe, you can tell the list what the attached image - that is
> encrypted with Moritz Muehlenhoff's and Florian Weimer's public keys -
> represent?
>
> Cheers (and thanks Mr. Moritz and Mr. Florian - who were the only I had
>
Thanks, but if you will notice, I have that link already listed at the
bottom of my message.
Also, you should not respond directly to people unless they specifically
ask you to do so. I did not ask.
On Wed, Jul 9, 2014 at 11:52 PM, Reid Sutherland wrote:
> https://www.debian.org/
>
> Go to CD
Thanks.
I'm new here. I was not on this list then. However, I just read the thread:
https://lists.debian.org/debian-security/2011/01/msg2.html
I saw that some of my concerns were mentioned there about obtaining and
verifying installation media, MITM attacks, etc.
I have previously verified
On Wed, Jul 9, 2014 at 11:23 PM, Michael Stone wrote:
> I frankly find it hard to believe that someone who is unwilling to click
> past the first link when researching actually cares much about any kind of
> writeup of threat models. I'll make it simple: if you're completely
> unsophisticated and
On Wed, Jul 09, 2014 at 11:11:44PM -0400, Darius Jahandarie wrote:
If Tux Q. Debiannewbie doesn't know what adversaries with what powers
they are/aren't protected against for their use cases without looking
hard and being a security expert, it's hard to make serious claims
that Debian is actually
On Wed, Jul 9, 2014 at 10:53 PM, Michael Stone wrote:
> On Wed, Jul 09, 2014 at 10:15:59PM -0400, Darius Jahandarie wrote:
>>
>> It would be nice for this information to be somewhere more formal than
>> in mailing list archives. Threat models are becoming increasingly
>> important to convey to end
On Wed, Jul 09, 2014 at 10:15:59PM -0400, Darius Jahandarie wrote:
It would be nice for this information to be somewhere more formal than
in mailing list archives. Threat models are becoming increasingly
important to convey to end users.
The mailing list discussion referenced the sources...
-
On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote:
For years I have been concerned with MITM attacks on Debian mirrors.
We discussed this literally within the past couple of months on this
list, at length. Have you read the archives, including the posts about
how to establish a trust
On Wed, Jul 9, 2014 at 10:11 PM, Michael Stone wrote:
> On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote:
>>
>> For years I have been concerned with MITM attacks on Debian mirrors.
>
>
> We discussed this literally within the past couple of months on this list,
> at length. Have you read
For years I have been concerned with MITM attacks on Debian mirrors.
I think the only valid solution would be to individually sign EACH package
with a valid GPG
signature from a trusted source.
I think EACH official package from Debian should be GPG signed by both
package maintainers and
also sig
Joel Rees dijo [Tue, Jul 08, 2014 at 11:11:09PM +0900]:
> >> Did you know that encrypting a picture sometimes results in a picture
> >> that looks like it has been through a random color-permuting filter?
> >
> > Can you proof it?
>
> Memory of coursework in encryption. The professor did some simp
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 in
On 07/07/2014 06:43 PM, Jeremie Marguerie wrote:
> On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT 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
On Tue, Jul 8, 2014 at 5:13 AM, Andrea Zwirner wrote:
> On 07/07/2014 13:09, Joel Rees wrote:
>
> Sorry Joel, I almost totally disagree with your vision on privacy and
> security, but I really i don't want to go into the merit of it, because
> I think Lou is representing my vision already; I only
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
mirr
On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Joel Rees:
> 2014/07/07 11:32 "Lou RUPPERT" :
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>>
>> Joel Rees:
>>> On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT
>>> wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512
Joel
On 07/07/2014 13:09, Joel Rees wrote:
Sorry Joel, I almost totally disagree with your vision on privacy and
security, but I really i don't want to go into the merit of it, because
I think Lou is representing my vision already; I only have a question:
> Did you know that encrypting a picture som
On 07/06/2014 10:31 PM, Lou RUPPERT wrote:
> Joel Rees:
>> On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT
>> wrote:
>>
>> As someone pointed out, verifying the mirror we've connected to is
>> not useful when we don't particularly have, or want, a way to
>> prevent a spook-owned mirror from joining
On 07/06/2014 10:20 PM, Michael Stone wrote:
> On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote:
>> And you know, the funny thing is that MSIE took to "warning" people
>> when there was a mix of encrypted and unencrypted data on a page. How
>> long ago? Yeah, I know, it was so they could
2014/07/07 11:32 "Lou RUPPERT" :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Joel Rees:
> > On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT
> > wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
> >>
> >> Joel Rees:
> >>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Joel Rees:
> On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>>
>> Joel Rees:
>>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>>> wrote:
> You don't need a warning when you are
On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote:
And you know, the funny thing is that MSIE took to "warning" people
when there was a mix of encrypted and unencrypted data on a page. How
long ago? Yeah, I know, it was so they could display that red herring
of a lock for "secured pages".
On Sat, Jul 5, 2014 at 6:14 AM, Hans-Christoph Steiner wrote:
>
> [...]
> I'm with Lou on this one,
I'm not surprised.
> there are already much bigger and better data sets
> for that.
So we should give them even more?
> According to this paper[1], Fedora 11+, Red Hat, SUSE, Google
> updates li
On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Joel Rees:
>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>> wrote:
>>>
>>> [rhetoric encouraging the use of TLS transport for mirrors] [list
>>> of current https mirrors]
>>
>>
On 07/04/2014 11:43 AM, Lou RUPPERT wrote:
> Joel Rees:
>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>> wrote:
>>>
>>> [rhetoric encouraging the use of TLS transport for mirrors] [list
>>> of current https mirrors]
>
>> Far be it from me to argue with ucalgary.ca, but one thing th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Joel Rees:
> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
> wrote:
>>
>> [rhetoric encouraging the use of TLS transport for mirrors] [list
>> of current https mirrors]
>
> Far be it from me to argue with ucalgary.ca, but one thing that
On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner wrote:
>
> [rhetoric encouraging the use of TLS transport for mirrors]
> [list of current https mirrors]
Far be it from me to argue with ucalgary.ca, but one thing that
bothers me about using TLS as a download transport is that, if I were
th
After the latest revelation about NSA tracking all Tor downloads[1] (with
source code!) and the whole "Debian mirrors and MITM" redux, I think we should
start talking about concrete steps that we can take to improve the situation.
The first things that came to mind would be quite easy to do:
* i
82 matches
Mail list logo
