Le 2011-09-17 05:18, David Kalnischkies a écrit :
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.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? So, could you show a scenario where non-atomatic creation of these files constitutes a problem?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. 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.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. 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. 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.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 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. 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.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… 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. I meant stable, the release current at any point in time, not Debian 6.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 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.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. IfUh, 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 ;) ) 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. I don't know if the change already exists in the form of patch, but it shouldn't be too mysterious.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? There is no need to merge a patch. This could be solved by reverting a change.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. 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. |