Gervase Markham wrote: > Nils Maier wrote: >> Disallowing those "corrupt LF" request is in fact what I wouldn't like >> to see. > > When they get a "link fingerprint check failed" error, how is a user to > tell the difference between "Oh, the webmaster screwed up" and "Someone > has trojaned this download"? > > Hard fail is the right way to go. > >> What if a webmaster somehow got the LF wrong? The user would get >> punished for it. > > The webmaster should have tested the link!
I can check my links, and the download files, but some of the download mirrors might not be up to date, yet, so we either have to choose to not use link fingerprint at all, or something should change in the implementation to prevent it from deleting any good files. >> Even SSL will let you continue if there is something wrong like >> non-matching hostnames; and SSL provides reliable security. > > We are changing this. > >> So I still am in favor of implementing LF within the actual consumers, >> as only they know how to handle stuff correctly, as only they got the >> full stream. > > I agree. > > Gerv The implementation seems to assume that we, the people using download mirrors, should know everything about the used download mirrors, which we clearly don't obviously, so removing good downloads because of a hash mismatch is wrong. The end-user is or better should have control over it, not a program, just like for visiting SSL and the Mozilla Firefox phishing protection. Sure, it might take a few bug reports, or some reporter writing a good article about this failure, but it won't be the download providers failing...but Mozilla Firefox. Kind Regards, Michael _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
