Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?)
Adam,
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.
> What are the problems to which I refer? One example;
> http://mirrors.ubuntu.com/mirrors.txt is sometimes used by Ubuntu to
> obtain a list of mirrors close to your location. In my region, I get
> 13 results. I checked every single mirror in that result list, and
> only one of them supported HTTPS. That particular mirror is one I
> seldom use as I have not found the uptime in the past to be
> particularly high.
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.
> But maybe you are more concerned that the distribution should support
> 3rd party repositories over HTTPS? Usually such "add-on" repositories
> host a very limited number of packages anyway, so it's probably not
> very difficult for ISPs and government agencies to know what you are
> running in that case regardless.
I guess that no one talked about third-party repos in this discussion.
> So basically I have the choice of a fast mirror, or one running HTTPS
> which might not be terribly reliable. Even if most people did prefer
> HTTPS, if finding fast mirrors supporting HTTPS is difficult, it will
> be much more difficult for probably any other distribution. So
> basically HTTPS-only for all official mirrors is impractical until
> this situation changes. And until it can be a default, what's the
> point of including the package by default?
>
> Or maybe you feel that by including that package, you'll encourage
> more mirrors to adopt HTTPS. I would hope that to be the case, but you
> might also have the opposite effect whereby mirror admins decide to
> drop support for such distributions due to the perceived
> inconvenience. Considering almost no mirrors are using it currently, I
> unfortunately suspect the later might be more accurate.
(I've changed the order of your paragraphs here to group the related ones.)
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. 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 you read again my last message, I wasn't arguing in favor nor
against the proposal. I only answered what apt-transport-https offers,
which is exactly what you asked about.
> 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.
Regards,
Tiago.
--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil
Reply to: