Re: Draft ballot for the GFDL vote
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ ] Choice 1: GFDL licensed works are unsuitable for main in all cases I would personally like to see this without the "in all cases" as an author could add extra statements clarifying their intention or interpretation of the license that could make the work DFSG-free. This also seems to be what the proposal is about. [ ] Choice 2: GFDL licensed works are free unless unmodifiable sections present Is this correct (I have trouble parsing this)? Maybe "GFDL licend works withour unmidifiable sections are free."? - -- - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEAEWAVYan35+NCKcRApWvAJ9+EWUJ24w1gYdZIe1ybyGiiCc1lQCeMazh b9Jf7VL28j40J/Bg3Lk1XNY= =zRPt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
use of md5sum for tally sheet
I'm not a cryptographer so I could be way off here. Could there be a problem with using the MD5 hash in the tally sheet? My concern is purely theoretic and I have absolutely no reason to doubt the secretary! When I submit my vote (for DPL elections) I receive a confirmation email with a moniker of FOO (as far as I can determine I don't have any influence of the chosen moniker). After the vote I check that the hash: echo "adejong FOO" | md5sum is in the tally sheet and has the correct vote (everybody does this right?). So far so good. The problem arises with the recent discoveries in hash-collisions for MD5. Is it possible to construct a moniker BAR that for another developer would result in the same MD5 hash as mine? If so, this could be exploited so that two developers look at the same row in the tally sheet and see their vote there (provided they voted the same). This would leave a row in the tally sheet that could be stuffed with a random MD5 hash and a vote of the secretary's choosing. This problem would of course be detected in a recount of the votes (signed emails) but it will not be detected from checking the tally sheet. Also, this problem obviously applies only to DPL elections as other votes are not anonymous. Again, I'm not doubting the integrity of the secretary and the ongoing vote. I'm just asking if this is purely theoretical or becoming practical? This issue was raised before: http://lists.debian.org/debian-vote/2003/03/msg00114.html and dismissed as impractical. A method for constructing MD5 collisions has been developed since then and I think the hashing landscape has changed somewhat so I think the question should be asked again. Some references on the MD5 collisions: http://www.cryptography.com/cnews/hash.html http://www.cits.rub.de/MD5Collisions/ http://en.wikipedia.org/wiki/Md5 These mainly describe inserting binary data in messages of around 1K. The data we're hashing is all ASCII and much shorter. Also it seems that most attacks insert a magic prefix rather than a suffix (and our moniker is at the back). This would suggest that there is not yet a ready-made attack available that would work in our case. A quick fix for this problem would be to also use a SHA1 (or other) hash with the SAME moniker (assuming finding a moniker that would result in a MD5 and SHA1 collision is still impractical). Another solution would be to let the voter choose the moniker. This could however have an influence on the anonymity of the vote. Better solutions can probably be found though. On a slightly (but not really) related note, would it be possible to get the tally sheet signed and sent to debian-vote after the vote? This would make tampering with the tally sheet after the vote harder. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Analysis of the ballot options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Well, most of those supporters probably did not believe the proposal > would or should have any effect on sarge's release. > > At least that was the case for me... And to not make the same mistake twice, is there some statement from the release manager somewhere regarding this vote? I would like to know exactly what effect the different choices would have on the release of sarge, accoring to the release manager. I have searched some lists a little but did not really find an answer to my question. Some of the questions that come to mind are: Can sarge realisticly be released before september 1st? (related to proposal A) Does the temporal change of the SC and rollback after the release of sarge cause problems for point releases of sarge? (related to several proposals) Does the list of "exempt" items from proposal C (documentation and firmware) cover enough items to be in line with the earlier release plan [1]? Is the next release really numbered 3.1? (relating to proposals C and E) [1] http://lists.debian.org/debian-devel-announce/2003/12/msg0.html - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA1vx+VYan35+NCKcRAtqCAKCBttN93dDfMmbYimfx6GvB3FItwQCgorsI cuD2Q7nNong5G4tBO8l16lM= =lqsX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The technical committee is waiting to see the outcome of this GR, but > informally >http://lists.debian.org/debian-ctte/2004/06/msg2.html If the RM has delegated the descision of the requirements for distributing sarge, could the TC take a stance on the proposals presented? Well looking at that post some of the points were: | ... It would be a bad idea to write a long document `under the gun'. ... This pretty much pleads agains proposal E. | ... Any such grandfather resolution should probably delegate reasonably | wide discretion about scope and interpretation to the Release Manager, | the Project Leader, the Committee or some other similar person or body, | to ensure that the resolution is sufficient and we don't need another | GR. ... Well none of the proposals really seem to do this, except for maybe proposals C and E. All the others fall back to the previous (ambiguous) SC. Would it be correct to assume that only the passing of proposal C will allow for a speedy release of sarge if it were up to the TC? - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA2MOmVYan35+NCKcRArucAKCVSmfDlGmSbIUodR70NU2ajkkdUgCgyu9b XlmXyfD8bGJtE6X28lZNDzg= =dSqs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
