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

Re: Bug#641769: [apt] fetches InRelease file, problematic on several mirrors (aka "Packages Hash Sum mismatch")

Le 2011-09-17 05:18, David Kalnischkies a écrit :
On Fri, Sep 16, 2011 at 19:44, Filipus Klutiero <chealer@gmail.com> wrote:
If you decrease the time between the dinstall (or equivalent) runs to lets
an hour as e.g. ubuntu does you get far more likely in situations in which
Release and Release.gpg doesn't belong together. Thats specifically one of
the reasons ftpmasters implemented it in 2009.

So, you are currently experience mirror-problems because we want to
protect you from mirror problems in the future. Crazy, heh? ;)
Could you clarify what incoherence scenario InRelease avoids? It is true
that Release and Release.gpg need to be either versioned or updated
simultaneously, but this problem applies to all files used to fetch indices,
which are all updated during stage 1 (except for InRelease). Therefore the
duration of incoherence should be insignificant in comparison to the problem
with InRelease.
Be careful with your guesses. If it would be that insignificant, why was it
implemented by ftpmasters?
I did specify "in comparison to the problem with InRelease", and as previously discussed, eliminating an HTTP request improves performance. This might also have more long-term advantages.
Also you are just looking at mirror sync,
the world consists of more than just mirror syncs! We have the creation
of these files for example which is far from being atomic at the moment.
So, could you show a scenario where non-atomatic creation of these files constitutes a problem?
Also, if you want to follow this route, from a security point is an InRelease
file better as a man-in-the-middle could drop the request for Release.gpg -
the archive has no signature then and APT will cry for an extra-yes, but
many users are pretty fast in pressing yes -- especially as they are
used to having these questions as not every thirdparty archive provides
a good signature… But for a real attack he would properly send modified
Release and co and doesn't respond to Release.gpg. Try that with
InRelease - sure, as we need to support the "old" way for a while these
kind of attacks can still be executed and dropping all requests for files
related to Release is a possibility, too, but one step at the time.
The problem of users getting used to this kind of prompts can be tackled by either {encouraging,making it easy for} third-party repositories to provide signatures, or by preventing users from needing third-party repositories.

If you still think administrators are too dumb for these prompts to be worth the security risk they pose, you could either request APT to simply fail when no signature is provided (at least for official sources), or to have prompts which get more attention (red text, "Yes, do as I say!", etc.).

Anyway, this issue is hopefully a short-term one.

So with disabling InRelease we would just hide the underlying problem,
this can't be a solution, especially not that early in the releasecycle.
After all, we are talking about unstable-only here.
I'm not sure what problem we would be "hiding" here. Mirrors using ftpsync
versions that don't handle InRelease correctly is only a problem insofar as
APT uses InRelease with problematic ftpsync versions...
That's a pretty short view. Forget InRelease for a moment: Are you really
willing to use a mirror there the admins didn't care? I am not.
If they are that sloppy to use old update-scripts, can i be sure that they
are not going to silently stop running their old scripts all together?
I am not using any specific mirror. Before I had to debug this issue, I was using my country's official mirrors round-robin. It may be a sad state of affairs that official mirrors do not have better administration, but that is the way it currently is.

I am not sure that my mirror won't stop updating, but that is the case for [almost] all Debian systems. APT is still in development and does not yet behave appropriately with mirrors.

As I said, there is not even a definition of what is an "old" ftpsync version. To a mirror administrator, using ftpsync 80286 may not appear worst than using apt 0.8.10.
You are later talking about versioning and co, how should it be possible
to use that if we are unable to use a single file after three years - or if
we want to be a bit more fair after eight months?

Not every damn feature should need six years before it can be used,
at least the last time i checked the file isn't called MultiRelease…
6 months is nothing in Debian development. Even if InRelease usage is reintroduced in this release cycle, it won't be generally used before at least another year.

I am not arguing that any specific time should be waited. I'm hoping that mirrors are updated quickly and that InRelease can be used quickly, but this needs works. I don't know how long it can take.

It is easy to add versioned indices even with non-cooperative mirrors. If several versions are kept, APT can just use the latest index version which has a complete set of index files.

As I said, this problem does not just affect unstable, it already affects
testing and would probably affect stable, and eventually all releases if
nothing is done.
stable doesn't have an InRelease file and apt/stable doesn't support it,
so there is no possibility for this to effect stable.
I meant stable, the release current at any point in time, not Debian 6.

Given that InRelease is used by others already without any problems it would
be a shame to revert them just because a single archive and (parts of) its
mirror network has problems with them -
even if this single archive is debian itself.
Uh, Debian is an actual GNU/Linux distribution, not just a draft. If
Uh, InRelease is an actual file, not just an inode waster.

I don't understand what you want to tell me with that line as i am not a draft
as well as various archives and complete debian-derivatives are not a draft.
And you seem to completely ignore that i said that e.g. for me and the mirrors
I use InRelease was never a problem, and i am reasonable sure that i was the
first users of it back in January after implementing it, so this problem
effects only parts of the mirror network - and as i have no knowledge about
mirrors i leave it up to the mirror team to decide how big this part is and
what should be done about that - and as long as this team doesn't say "David,
you bloody idiot, revert it or we will tell mirror-admins where you live to
take care of you." i assume i can be of no help.
(but i am sure the mirror-team would have worded it differently ;) )
I am not at all ignoring that parts of the mirror network do not have this problem; as I wrote, my own mirror was fixed before I filed this report.
Let's also not ignore that preventing this kind of issue is not the sole responsibility of the mirrors team.

I don't understand your reply very well, but let me rephrase what I wrote. Debian is not just a platform on which operating systems can be built. Debian is itself a finished product. Even though we can think of derivatives, the most important is to ship a good product. We shouldn't tolerate issues just because they improve a derivative.

Even if we want to be derivative-friendly, there are ways to do things without harming Debian. In this case, I doubt that most derivatives are doing better than Debian, and those doing better should be able to patch their APT if they wish, but even if they were, things can be flagged as Debian-specific.

If offering a patch is not enough, feel free to leave code to ease having
InRelease support, perhaps a compile-time option. Or even to make the APT
source support InRelease by default and to only disable it in Debian. All
I'm saying is that something needs to be done for Debian proper.
Wait, where is this mysterious patch you are talking about?
I don't know if the change already exists in the form of patch, but it shouldn't be too mysterious.
I already said that i would try my best to merge a patch, but my time
is limited and i prefer to do in my free-time stuff i want to do and not what
others think i have to, so i am not going to write that patch myself or
for that matter any patch even only remotely connected to #636292
without a good motivation to do so.
End of the story.
There is no need to merge a patch. This could be solved by reverting a change.
In any case, nobody asked you to do anything here, and if you don't feel like working on this, there is no need to discourage others from doing so.

Reply to: