Re: aerb "file has been altered" errors after removing files in branch
Calvin Webster <[email protected]> Mon, 25 Apr 2016 07:57:57 -0400
| Newsgroups | gmane.comp.version-control.aegis.user |
|---|---|
| Message-ID | <1461585477.14245.152.camel@klink> |
--===============8923396856316607937== Content-Type: multipart/alternative; boundary="=-/JHTAsnC2K6iUR+JXcar" --=-/JHTAsnC2K6iUR+JXcar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-04-25 at 13:14 +0200, Ralf Fassel wrote: > * Calvin Webster > | > The crypto there is a hash based on which aegis determines whether = a > | > file has changed. The diff_file_fp entry is probably what you're > | > looking for. > |=20 > | What is being used to generate those hashes? At first I thought they > | were checksums, judging by the size probably sha256. When I compared = a > | sha256 sum I found that these are 77 characters whereas sha256sum has= hes > | are 65 characters. >=20 > According to the 4.24 documentation, there is the 'aefp' program to > calculate the file fingerprint. The manpage for 'aefp' > documents the crypto field as a combination of various hashes. >=20 > The fingerprint is based on Dan Berstien <[email protected]= u> public domain fingerprint 0.50 beta > package 930809, posted to the alt.sources newsgroup. This program p= roduces identical results; the > expected test results were generated using Dan=E2=80=99s package. > The fingerprint is a base-64-sanely-encoded fingerprint of the inpu= t. Imagine this fingerprint as something > universal and permanent. A fingerprint is 76 characters long, conta= ining the following: > 1. > A Snefru-8 (version 2.5, 8 passes, 512->256) hash. (Derived from t= he Xerox Secure Hash Function.) > 2. > An MD5 hash, as per RFC 1321. (Derived from the RSADSI MD5 Message= -Digest Algorithm.) > 3. > A CRC checksum, as in the new cksum utility. > 4. > Length modulo 2=CB=8640. >=20 > See > http://aegis.sourceforge.net/refman.pdf > and the 'aefp' references and manpage in there. >=20 > Note that 'aefp' seems to be built to test aegis, > but is not installed by default. Yes, thanks. While searching the Aegis source for "crypto" this weekend I found the aefp man page. After reading it I discovered, as you say, it's not installed. I ran "rpmbuild -bi" on the source RPM but the binary doesn't appear to have been built there and I'm not sure how to get it built. In case it was a built-in without an alias I tried using as "aegis -fp buildinfo" but no cigar. >=20 > | If I'm going to fool aegis I need to be able to generate a similar ha= sh. >=20 > I'm not sure whether this is a good road to go... If aegis complains > at this level, there is probably an error in the process logic which > will probably repeat on the next step. Can't you just let the > change/branch in question "rest in peace"? This branch must be integrated. We are preparing to release a major revision (branch 23) and must integrate this minor revision (branch 15023) in order to complete that. This stubborn file was among a large number of derived files that were mistakenly integrated previously. All the others were successfully removed with "aerm". Something happened with this file that is causing all this grief. The only time I get this error is when I try to review_begin on this branch. None of the changes in the branch had issues. If there is a simpler way to rid myself of this blocking error I'd be happy to hear it. I don't care about the history of this file or its content in this location.=20 Thank you for the info. ./Cal --=-/JHTAsnC2K6iUR+JXcar Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2"> </HEAD> <BODY> On Mon, 2016-04-25 at 13:14 +0200, Ralf Fassel wrote: <BLOCKQUOTE TYPE=CITE> <PRE> * Calvin Webster | > The crypto there is a hash based on which aegis determines whether a | > file has changed. The diff_file_fp entry is probably what you're | > looking for. | | What is being used to generate those hashes? At first I thought they | were checksums, judging by the size probably sha256. When I compared a | sha256 sum I found that these are 77 characters whereas sha256sum hashes | are 65 characters. According to the 4.24 documentation, there is the 'aefp' program to calculate the file fingerprint. The manpage for 'aefp' documents the crypto field as a combination of various hashes. The fingerprint is based on Dan Berstien <<A HREF="mailto:[email protected]">[email protected]</A>> public domain fingerprint 0.50 beta package 930809, posted to the alt.sources newsgroup. This program produces identical results; the expected test results were generated using Dan’s package. The fingerprint is a base-64-sanely-encoded fingerprint of the input. Imagine this fingerprint as something universal and permanent. A fingerprint is 76 characters long, containing the following: 1. A Snefru-8 (version 2.5, 8 passes, 512->256) hash. (Derived from the Xerox Secure Hash Function.) 2. An MD5 hash, as per RFC 1321. (Derived from the RSADSI MD5 Message-Digest Algorithm.) 3. A CRC checksum, as in the new cksum utility. 4. Length modulo 2ˆ40. See <A HREF="http://aegis.sourceforge.net/refman.pdf">http://aegis.sourceforge.net/refman.pdf</A> and the 'aefp' references and manpage in there. Note that 'aefp' seems to be built to test aegis, but is not installed by default. </PRE> </BLOCKQUOTE> <BR> <B>Yes, thanks. While searching the Aegis source for "crypto" this weekend I found the aefp man page. After reading it I discovered, as you say, it's not installed. I ran "rpmbuild -bi" on the source RPM but the binary doesn't appear to have been built there and I'm not sure how to get it built. In case it was a built-in without an alias I tried using as "aegis -fp buildinfo" but no cigar.</B><BR> <BR> <BLOCKQUOTE TYPE=CITE> <PRE> | If I'm going to fool aegis I need to be able to generate a similar hash. I'm not sure whether this is a good road to go... If aegis complains at this level, there is probably an error in the process logic which will probably repeat on the next step. Can't you just let the change/branch in question "rest in peace"? </PRE> </BLOCKQUOTE> <BR> <B>This branch must be integrated. We are preparing to release a major revision (branch 23) and must integrate this minor revision (branch 15023) in order to complete that.</B><BR> <BR> <B>This stubborn file was among a large number of derived files that were mistakenly integrated previously. All the others were successfully removed with "aerm". Something happened with this file that is causing all this grief. The only time I get this error is when I try to review_begin on this branch. None of the changes in the branch had issues.</B><BR> <BR> <BR> <BR> <B>If there is a simpler way to rid myself of this blocking error I'd be happy to hear it. I don't care about the history of this file or its content in this location. </B><BR> <BR> <B>Thank you for the info.</B><BR> <BR> <B>./Cal</B> </BODY> </HTML> --=-/JHTAsnC2K6iUR+JXcar-- --===============8923396856316607937== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQWVnaXMtdXNl cnMgbWFpbGluZyBsaXN0CkFlZ2lzLXVzZXJzQGxpc3RzLmF1dWcub3JnLmF1Cmh0dHBzOi8vbGlz dHMuYXV1Zy5vcmcuYXUvbGlzdGluZm8vYWVnaXMtdXNlcnMK --===============8923396856316607937==--