Bug#641769: [apt] fetches InRelease file, problematic on several mirrors (aka "Packages Hash Sum mismatch")
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
>> say
>> 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? 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.
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.
>> 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?
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…
> 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.
>> 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 ;) )
> 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 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.
Best regards
David Kalnischkies
Reply to: