[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?)

On Tue, Mar 15, 2016 at 11:27:26AM -0300, Tiago Ilieve wrote:
> On 15 March 2016 at 01:46, Adam Bolte <abolte@systemsaviour.com>
> wrote:

> > I already pointed out a workaround for that. I use an apt-cache-ng
> > server on my home LAN which improves both privacy and
> > efficiency. Other people/companies run a local mirror for even
> > better privacy and to avoid issues when remote networks or servers
> > are unavailable. There are easy ways to address your concern which
> > don't introduce problems.
> Your use case isn't everyone's use case. For instance, using
> apt-cacher on my laptop wouldn't help me in any way, because nearly
> every package download would be a new transfer being done in the
> clear. I would probably be better served by apt-transport-tor in
> this case, as you suggests later, but apt-transport-https would be
> easier to use and fulfills my necessity.

Are you quite sure? In some situations that involve only a single
machine, it's possible the size alone of what you are downloading from
your repository is enough to give the content away. Tor would at least
completely hide the fact that you are even downloading a package

In my opinion, if privacy is the primary concern, go all the way and
use Tor.

> I had so many problems with Ubuntu's "mirror.txt" that I prefer to
> not talk about it. Can we focus on what Debian offers?
> httpredir.debian.org is (IMHO) a much better service. I'll get into
> it later in this message.

It really doesn't matter. I just used that as a quick way to obtain a
list of mirrors in my region.

> I guess that no one talked about third-party repos in this
> discussion.

Just covering all bases.

> This is exactly what Charles is asking: what do we think about this?
> Would this be a shot in the foot? Of course I would like to more
> mirrors to adopt HTTPS, but this shouldn't be imposed by the way
> newer distributions handles connections the those servers.
> Actually, maybe I'm wrong, but AFAICT, apt-transport-https *enables*
> the support for HTTPS mirrors, it *doesn't forces* every one of them
> to use encrypted/authenticated connections.

It allows https to be used in your sources.list-type files. It
certainly doesn't revoke any other functionality you would normally

> Then we have the problem of how we can use httpredir.debian.org this
> way, but that's another issue (which may already been solved, but
> I'm not aware of).

If the package apt-transport-https was pre-installed, and all
supported proxy programs such as apt-cacher, apt-cacher-ng, etc. also
supported HTTPS (and I'm not sure that they do), httpredir should
perhaps be able to return https URLs.

Then it's just a matter of how you make that leap. Would most people
be happy to use HTTP when HTTPS is available? Would https mirrors be
happy with a potentially massive increase in traffic as a result of
people switching to the one deemed more secure? Would Debian be happy
to trust that mirrors keep their certificates managed correctly to
avoid package update errors? etc. It's a lot to discuss, and (as I
think someone mentioned earlier) I don't think this is really the
correct list for it.

> > I'm all for privacy, but I don't think the argument for inclusion
> > of the package has been very well thought out. I think the
> > inclusion of apt-transport-tor makes much more sense given your
> > stated concern.
> Like I said in the beginning of this message, Tor is not as easy to
> use as (and one can argue that it is not a substitute to)
> HTTPS. Then, it doesn't makes sense to include it by default.

Well that's one opinion, upon which your conclusion is based. :)

In my opinion, I don't expect every single mirror would ever switch to
HTTPS, or if they did, would always use certificates that are properly
managed and trusted by the OS. I'd rather have the OS configure Tor
out of the box, and have a more reliable situation for updates along
with much better privacy - if privacy is the focus. In practise, since
I use a proxy anyway which gives me a level of privacy I'm comfortable
with, I would probably prefer plain HTTP - at least until the above
concerns have been discussed and a plan is in place.

Attachment: signature.asc
Description: Digital signature

Reply to: