From: Jerome <rom...@ya...> - 2014-03-18 14:32:28
|
An alternative is maybe to look at tags on git? https://www.gramps-project.org/wiki/index.php?title=What_to_do_for_a_release#Create_a_tag We generated last tarballs from tag! This also avoids any 'polution' after some local testing (translations, run via command line, make, etc ...), and it runs last check into a clean environment. https://www.gramps-project.org/wiki/index.php?title=What_to_do_for_a_release#Release_from_tag With last releases, I did not have to merge changes on or from tag. eg, changes on debian stuff have been done on gramps40 branch itself, and after the release, during experimental .deb generation. I suppose that a git snapshot via tag, even away from a real identification and signature, is also a safe way for checking gramps code, and could be an alternate trusted source? OK, content of tag can be modified after the release via git, but maybe also with a change on the release version. gramps/gen/const.py - VERSION += "-1" + VERSION += "-2" Jérôme Le mar. 4 mars 2014 at 21:21, Ross Gammon <ro...@th...> a écrit : > On 03/04/2014 05:31 PM, John Ralls wrote: >> >> On Mar 4, 2014, at 1:50 AM, Jerome <rom...@ya...> wrote: >> >>> Note, it seems to me that some linux distributions (eg, Gentoo) >>> are only verificating integrity via sha1 or md5? >>> >>> It is not very visible, but each files under Sourceforge provides >>> it hashes. >>> >>> >>> http://sourceforge.net/p/forge/documentation/Verifying%20downloaded%20files/ >>> >>> eg, for gramps-4.0.3.tar.gz >>> >>> SHA1: eff2e6b802c1e4747cd218a2d8f3c346346642d0 >>> MD5: 637d4cecbdca4a72832e1696f2412276 >>> >>> In the past, we replaced one release tarball by an other one (same >>> name), and we have learned that in this case, either use a new >>> release version (x.x.x-1) or a new release (x.x. +1), because >>> gentoo needs a safe and consistent hash for building via sources. >>> >>>> See: >>>> >>> >>> http://lintian.debian.org/tags/debian-watch-may-check-gpg-signature.html >>> >>> I suppose it is specific to *.deb files? >>> I am able to build some .deb files, but they will not be the >>> "official" Debian or Ubuntu, etc ... packages. >>> >> >> Gnome's jhbuild does that too if you tell it the hash (it can use >> several different kinds) and Gnome's release program generates a >> sha256 hash and publishes it when you release a new tarball. That >> affords some security in the case of a mirror redirect when you >> download (the way SF does it) but not when the mirror redirect >> happens when browsing (the way Gnome does) because as I said >> earlier, if an attacker can replace the tarball he can also replace >> the hash. Considering the recent discovery that 300K home routers >> have been compromised and their DNS reconfigured, this isn't an >> entirely paranoid concern. >> >> Unfortunately the Debian/CAcert "web of trust" apparently lacks >> adequate controls to satisfy Mozilla [1] so the root cert isn't >> included in any browser, which increases its vulnerability to forged >> signatures being accepted as valid. >> >> Regards, >> John Ralls >> >> [1] http://en.wikipedia.org/wiki/CAcert.org >> >> > Thanks guys for your thoughts and input. When I reported the incorrect > link that John spotted on the lintian website, I also took the > opportunity to ask if there was any useful guidance on how a small > volunteer multi-platform OS project could implement something > suitable. > > For now, you have given me all the good reasons why I should just > override the warning. > > But we should keep our eyes open for a better solution in the future > though. > > Ross > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually > works. > Faster operations. Version large binaries. Built-in WAN optimization > and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |