* [gentoo-dev] Tree-signing GLEPs update
@ 2010-01-31 9:20 Robin H. Johnson
2010-01-31 9:48 ` [gentoo-dev] GLEP58 - MetaManifest Robin H. Johnson
` (4 more replies)
0 siblings, 5 replies; 16+ messages in thread
From: Robin H. Johnson @ 2010-01-31 9:20 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]
I'm putting the remaining tree-signing GLEPs up here on the lists again,
now that I've integrated the requested changes to them. I hoped to get
them out before now, but I've had a lot going on as usual.
Thanks to the following for their questions:
- ulm
- Calchan
- solar
Hopefully I haven't left any bits out.
Further questions are strongly encouraged at this point, because there
is even less chance I'm going to be present at the next council meeting,
as I'll be in Brussels at the time.
Changes I've made will be summarized in each GLEP mail in this thread.
The prototype code remains at the same place in CVS:
http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/prototype/
- generate-metamanifest.py generates a top-level MetaManifest only, not
yet updated for subdirectory Manifests. (I just split the MetaManifest
with some bad Perl for size estimations).
- gnupg-verify/ speed-daemon ways to verify many signed files. Once you
dodge the bad gpgme design of one exec per verify, you're basically
limited only by seek time for handling 10k files.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* [gentoo-dev] GLEP58 - MetaManifest 2010-01-31 9:20 [gentoo-dev] Tree-signing GLEPs update Robin H. Johnson @ 2010-01-31 9:48 ` Robin H. Johnson 2010-02-02 6:27 ` Denis Dupeyron 2010-01-31 9:57 ` [gentoo-dev] GLEP59 - Manifest2 hashes Robin H. Johnson ` (3 subsequent siblings) 4 siblings, 1 reply; 16+ messages in thread From: Robin H. Johnson @ 2010-01-31 9:48 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 589 bytes --] Changes: - Provide a summary of the generation method. - Clarify that every file in the tree must be included. - Manifests at the first level of the directory structure are now REQUIRED to help mitigate the cost of redistribution. Other levels are still optional. - Scripts are permitted generate multiple levels of Manifests in parallel to save the cost of traversing the tree multiple times. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #1.2: glep-0058.txt --] [-- Type: text/plain, Size: 14338 bytes --] GLEP: 58 Title: Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest Version: $Revision: 1.7 $ Last-Modified: $Date: 2010/01/31 07:53:30 $ Author: Robin Hugh Johnson <robbat2@gentoo.org>, Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 44, 60 Created: October 2006 Updated: November 2007, June 2008, July 2008, October 2008, January 2010 Post-History: December 2009, January 2010 ======== Abstract ======== MetaManifest provides a means of verifiable distribution from Gentoo Infrastructure to a user system, while data is conveyed over completely untrusted networks and system, by extending the Manifest2 specification, and adding a top-level Manifest file, with support for other nested Manifests. ========== Motivation ========== As part of a comprehensive security plan, we need a way to prove that something originating from Gentoo as an organization (read Gentoo-owned hardware, run by infrastructure), has not been tampered with. This allows the usage of third-party rsync mirrors, without worrying that they have modified something critical (e.g. eclasses, which are still unsigned). Securing the untrusted distribution is one of the easier tasks in the security plan - in short, all that is required is having a hash of every item in the tree, and signing that hash to prove it came from Gentoo. Ironically we have a hashed and signed distribution (it's just not used by most users, due to it's drawbacks): Our tree snapshot tarballs have hashes and signatures. So now we want to add the same verification to our material that is distributed by rsync. We already provide hashes of subsets of the tree - our Manifests protect individual packages. However metadata, eclasses and profiles are not protected at this time. The directories of packages and distfiles are NOT covered by this, as they are not distributed by rsync. This portion of the tree-signing work provides only the following guarantee: A user can prove that the tree from the Gentoo infrastructure has not been tampered with since leaving the Gentoo infrastructure. No other guarantees, either implicit or explicit are made. Additionally, distributing a set of the most recent MetaManifests from a trusted source allows validation of trees that come from community mirrors, and allows detection of all cases of malicious mirrors (either by deliberate delay, replay [C08a, C08b] or alteration). ============= Specification ============= For lack of a better name, the following solution should be known as the MetaManifest. Those responsible for the name have already been sacked. MetaManifest basically contains hashes of every file in the tree, either directly or indirectly. The direct case applies to ANY file that does not appear in an existing Manifest file (e.g. eclasses, Manifest files themselves). The indirect case is covered by the CONTENTS of existing Manifest files. If the Manifest itself is correct, we know that by tracking the hash of the Manifest, we can be assured that the contents are protected. In the following, the MetaManifest file is a file named 'Manifest', located at the root of a repository. --------------------------------------------- Procedure for creating the MetaManifest file: --------------------------------------------- Summary: ======== The objective of creating the MetaManifest file(s) is to ensure that every single file in the tree occurs in at least one Manifest. Process: ======== 1. Start at the root of the Gentoo Portage tree (gentoo-x86, although this procedure applies to overlays as well). 2. Initialize two unordered sets: COVERED, ALL. 1. 'ALL' shall contain every file that exists in the present tree. 2. 'COVERED' shall contain EVERY file that is mentioned in an existing Manifest2. If a file is mentioned in a Manifest2, but does not exist, it must still be included. No files should be excluded. 3. Traverse the tree, depth-first. 1. At the top level only, ignore the following directories: distfiles, packages, local. 2. If a directory contains a Manifest file, extract all relevant local files from it (presently: AUX, MISC, EBUILD; but should follow the evolution of Manifest2 entry types per [#GLEP60]), and place them into the COVERED set. 3. Recursively add every file in the directory to the ALL set, pursuant to the exclusion list as mentioned in [#GLEP60]. 4. Produce a new set, UNCOVERED, as the set-difference (ALL)-(COVERED). This is every item that is not covered by another Manifest, or part of an exclusion list. 5. If an existing MetaManifest file is present, remove it. 6. For each file in UNCOVERED, assign a Manifest2 type, produce the hashes, and add with the filetype to the MetaManifest file. 7. For unique identification of the MetaManifest, a header line should be included, using the exact contents of the metadata/timestamp.x file, so that a MetaManifest may be tied back to a tree as distributed by the rsync mirror system. The string of 'metadata/timestamp.x' should be included to identify this revision of MetaManifest generation. e.g.: "Timestamp: metadata/timestamp.x: 1215722461 Thu Jul 10 20:41:01 2008 UTC" The package manager MUST not use the identifying string as a filename. 8. The MetaManifest must ultimately be GnuPG-signed. 1. For the initial implementation, the same key as used for snapshot tarball signing is sufficient. 2. For the future, the key used for fully automated signing by infra should not be on the same keyring as developer keys. See [#GLEPxx+3 for further notes]. Notes: ====== The above does not conflict the proposal contained in GLEP33, which restructure eclasses to include subdirectories and Manifest files, as the Manifest rules above still provide indirect verification for all files after the GLEP33 restructuring if it comes to pass. Additional levels of Manifests are required, such as per-category, and in the eclasses, profiles and metadata directories. This ensures that a change to a singular file causes the smallest possible overall change in the Manifests as propagated. Creation of the additional levels of Manifests uses the same process as described above, simply starting at a different root point. MetaManifest generation will take place as part of the existing process by infrastructure that takes the contents of CVS and prepares it for distribution via rsync, which includes generating metadata. In-tree Manifest files are not validated at this point, as they are assumed to be correct. -------------------------------------------------------- Verification of one or more items from the MetaManifest: -------------------------------------------------------- There are two times that this may happen: firstly, immediately after the rsync has completed - this has the advantage that the kernel file cache is hot, and checking the entire tree can be accomplished quickly. Secondly, the MetaManifest should be checked during installation of a package. ---------------------------------------------------- Procedure for verifying an item in the MetaManifest: ---------------------------------------------------- In the following, I've used term 'M2-verify' to note following the hash verification procedures as defined by the Manifest2 format - which compromise checking the file length, and that the hashes match. Which filetypes may be ignored on missing is discussed in [#GLEP60]. 1. Check the GnuPG signature on the MetaManifest against the keyring of automated Gentoo keys. See [#GLEPxx+3] for full details regarding verification of GnuPG signatures. 1. Abort if the signature check fails. 2. Check the Timestamp header. If it is significantly out of date compared to the local clock or a trusted source, halt or require manual intervention from the user. 3. For a verification of the tree following an rsync: 1. Build a set 'ALL' of every file covered by the rsync. (exclude distfiles/, packages/, local/) 2. M2-verify every entry in the MetaManifest, descending into inferior Manifests as needed. Place the relative path of every checked item into a set 'COVERED'. 3. Construct the set 'UNCOVERED' by set-difference between the ALL and COVERED sets. 4. For each file in the UNCOVERED set, assign a Manifest2 filetype. 5. If the filetype for any file in the UNCOVERED set requires a halt on error, abort and display a suitable error. 6. Completed verification 4. If checking at the installation of a package: 1. M2-verify the entry in MetaManifest for the Manifest 2. M2-verify all relevant metadata/ contents if metadata/ is being used in any way (optionally done before dependency checking). 3. M2-verifying the contents of the Manifest. 4. Perform M2-verification of all eclasses and profiles used (both directly and indirectly) by the ebuild. Notes: ====== 1. For initial implementations, it is acceptable to check EVERY item in the eclass and profiles directory, rather than tracking the exact files used by every eclass (see note #2). Later implementations should strive to only verify individual eclasses and profiles as needed. 2. Tracking of exact files is of specific significance to the libtool eclass, as it stores patches under eclass/ELT-patches, and as such that would not be picked up by any tracing of the inherit function. This may be alleviated by a later eclass and ebuild variable that explicitly declares what files from the tree are used by a package. ==================== Implementation Notes ==================== For this portion of the tree-signing work, no actions are required of the individual Gentoo developers. They will continue to develop and commit as they do presently, and the MetaManifest is added by Infrastructure during the tree generation process, and distributed to users. Any scripts generating Manifests and the MetaManifest may find it useful to generate multiple levels of Manifests in parallel, and this is explicitly permitted, provided that every file in the tree is covered by at least one Manifest or the MetaManifest file. The uppermost Manifest (MetaManifest) is the only item that does not occur in any other Manifest file, but is instead GPG-signed to enable it's validation. -------------------------------------------- MetaManifest and the new Manifest2 filetypes -------------------------------------------- While [#GLEP60] describes the addition of new filetypes, these are NOT needed for implementation of the MetaManifest proposal. Without the new filetypes, all entries in the MetaManifest would be of type 'MISC'. ---------------------------------------------------- Timestamps & Additional distribution of MetaManifest ---------------------------------------------------- As discussed by [C08a,C08b], malicious third-party mirrors may use the principles of exclusion and replay to deny an update to clients, while at the same time recording the identity of clients to attack. This should be guarded against by including a timestamp in the header of the MetaManifest, as well as distributing the latest MetaManifests by a trusted channel. On all rsync mirrors directly maintained by the Gentoo infrastructure, and not on community mirrors, there should be a new module 'gentoo-portage-metamanifests'. Within this module, all MetaManifests for a recent time frame (e.g. one week) should be kept, named as "MetaManifest.$TS", where $TS is the timestamp from inside the file. The most recent MetaManifest should always be symlinked as MetaManifest.current. The possibility of serving the recent MetaManifests via HTTPS should also be explored to mitigate man-in-the-middle attacks. The package manager should obtain MetaManifest.current and use it to decide is the tree is too out of date per operation #2 of the verification process. The decision about freshness should be a user-configuration setting, with the ability to override. -------------------------------- MetaManifest size considerations -------------------------------- With only two levels of Manifests (per-package and top-level), every rsync will cause a lot of traffic transferring the modified top-level MetaManifest. To reduce this, first-level directory Manifests are required. Alternatively, if the distribution method efficiently handles small patch-like changes in an existing file, using an uncompressed MetaManifest may be acceptable (this would primarily be distributed version control systems). Other suggestions in reducing this traffic are welcomed. ======================= Backwards Compatibility ======================= - There are no backwards compatibility issues, as old versions of Portage do not look for a Manifest file at the top level of the tree. - Manifest2-aware versions of Portage ignore all entries that they are not certain how to handle. Enabling headers and PGP signing to be conducted easily. ====== Thanks ====== I'd like to thank the following people for input on this GLEP. - Patrick Lauer (patrick): Prodding me to get all of the tree-signing work finished, and helping to edit. - Ciaran McCreesh (ciaranm): Paludis Manifest2 - Brian Harring (ferringb): pkgcore Manifest2 - Marius Mauch (genone) & Zac Medico (zmedico): Portage Manifest2 - Ned Ludd (solar) - Security concept review ========== References ========== [C08a] Cappos, J et al. (2008). "Package Management Security". University of Arizona Technical Report TR08-02. Available online from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf [C08b] Cappos, J et al. (2008). "Attacks on Package Managers" Available online at: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/ ========= Copyright ========= Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0. vim: tw=72 ts=2 expandtab: [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP58 - MetaManifest 2010-01-31 9:48 ` [gentoo-dev] GLEP58 - MetaManifest Robin H. Johnson @ 2010-02-02 6:27 ` Denis Dupeyron 2010-02-02 7:35 ` Robin H. Johnson 0 siblings, 1 reply; 16+ messages in thread From: Denis Dupeyron @ 2010-02-02 6:27 UTC (permalink / raw To: gentoo-dev You'll find below an email from solar to Robin about MetaManifest. I'm adding it to this thread (with solar's authorization) as it seems pertinent. Denis. On Thu, Jan 21, 2010 at 6:51 PM, Ned Ludd <solar@gentoo.org> wrote: > Robin, > > I recall you wanted me to mail you what we talked about last nite in > #gentoo-portage and I'll CC: the council so they have an idea what to > maybe expect. > > So in our talking last night we discussed the fact that if the Manifest > format has to change why not just get rid of it all together, and save > some serious in tree space with the new MetaManifest's taking over all > together. This would include MetaManifest's at the 2-level. > You said the MetaManifest would need about 4 fields in them to describe > the distfiles etc. Devs would still push normal Manifest's to the cvs > tree so DIST can be obtained by the backend infra scripts. But those > Manifest's could be dropped from the mirroring. if [ -e CVS ] then > portage would need to use the existing Manifest's > > This method would hands down win my vote. As you know I'm not a fan of > format changes in general as they can make the Gentoo experience suck, > but if we are going to change formats. Lets do it right. > > The only downside I can see in this method is for people like drobbins > who mirror our tree but overlay right on top of it then provide it back > out. In such cases we should provide our backend scripts to the public > so they can re MetaManifest. > > I'm probably forgetting all sorts of details from the chat. But > hopefully this is enough to remind you, as well as giving the other > council ppl an idea of what to maybe expect. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP58 - MetaManifest 2010-02-02 6:27 ` Denis Dupeyron @ 2010-02-02 7:35 ` Robin H. Johnson 0 siblings, 0 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-02-02 7:35 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 4495 bytes --] On Mon, Feb 01, 2010 at 11:27:01PM -0700, Denis Dupeyron wrote: > You'll find below an email from solar to Robin about MetaManifest. I'm > adding it to this thread (with solar's authorization) as it seems > pertinent. > > Denis. > > On Thu, Jan 21, 2010 at 6:51 PM, Ned Ludd <solar@gentoo.org> wrote: > > Robin, > > > > I recall you wanted me to mail you what we talked about last nite in > > #gentoo-portage and I'll CC: the council so they have an idea what to > > maybe expect. > > > > So in our talking last night we discussed the fact that if the Manifest > > format has to change why not just get rid of it all together, and save > > some serious in tree space with the new MetaManifest's taking over all > > together. This would include MetaManifest's at the 2-level. > > You said the MetaManifest would need about 4 fields in them to describe > > the distfiles etc. Devs would still push normal Manifest's to the cvs > > tree so DIST can be obtained by the backend infra scripts. But those > > Manifest's could be dropped from the mirroring. if [ -e CVS ] then > > portage would need to use the existing Manifest's First, I'd like to clarify one things for all other readers, as it isn't clear for anybody else just reading this email. ================ Solar's proposal does the following: 1. Tree in CVS/VCS: - drop ALL Manifest2 lines _EXCEPT_ DIST. 2. Tree available via rsync: - Manifests at the following locations ONLY: - /MetaManifest - /${CAT}/Manifest - /profiles/Manifest - /eclasses/Manifest - /metadata/cache/${CAT}/Manifest - /metadata/glsa/Manifest - Data from ALL Manifests get moved to one of the above. - MISC/EBUILD etc (non-DIST) lines generated at the same time that the rsync tree is prepared. 3. Net savings of approximately 13000 inodes, as the per package Manifest data is now one level up, saving the inode from the package. ================ Now, I believe that this above should be possible WITHIN the framework of my proposed MetaManifest changes. I specifically stated in GLEP58: === The objective of creating the MetaManifest file(s) is to ensure that every single file in the tree occurs in at least one Manifest. === My proposals did not cover removing other Manifest files per solar's suggestion, as I perceived that to be a much larger objective than my goal of actually securing the existing tree distribution. I am entirely open to solar's suggestions, in an additional GLEP, as they will require that Portage support IS fully in place, because old versions WILL fail on a tree without per-package Manifest. > > This method would hands down win my vote. As you know I'm not a fan of > > format changes in general as they can make the Gentoo experience suck, > > but if we are going to change formats. Lets do it right. A potential plan for GLEP58 and solar's changes would be: 1. Council approves GLEP58. 2. Portage support is added, we add MetaManifests everywhere needed (top-level, categories, metadata, eclass etc) in the tree. 3. Old Portage versions still work at this point, because they ignore the other Manifest files. 4. Wait 6-12 months for Portage upgrade cycle. 5. Change the content of the MetaManifests to be per solar's proposal. 6. Drop per-package Manifests from the tree. Thus there is ZERO breakage. A similar timeline is required for ALL of the other GLEPs I have proposed. GLEP59 - Hashes: - Can add new hashes right now. - Some of the old hashes we can remove right now. - Have to keep just one old hash for old Portage to still work. GLEP60 - Filetypes: - Can add new types right now. - Cannot remove ANY types for a full upgrade cycle. GLEP61 - Compression: - (uncofirmed) Cannot add the compressed files in per-package locations until the upgrade cycle is done, as old Portage will complain about their existence. > The only downside I can see in this method is for people like drobbins > who mirror our tree but overlay right on top of it then provide it back > out. In such cases we should provide our backend scripts to the public > so they can re MetaManifest. My MetaManifest generation script is already public. I do agree that we could do better in documenting and publishing our older rsync generation scripts. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] GLEP59 - Manifest2 hashes 2010-01-31 9:20 [gentoo-dev] Tree-signing GLEPs update Robin H. Johnson 2010-01-31 9:48 ` [gentoo-dev] GLEP58 - MetaManifest Robin H. Johnson @ 2010-01-31 9:57 ` Robin H. Johnson 2010-02-01 5:05 ` Robin H. Johnson 2010-02-01 8:23 ` Doug Goldstein 2010-01-31 10:01 ` [gentoo-dev] GLEP60 - Manifest2 filetypes Robin H. Johnson ` (2 subsequent siblings) 4 siblings, 2 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-01-31 9:57 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 600 bytes --] Changes: - This GLEP should be considered regardless of GLEP58 passes, as it has independent value. - Python 2.5 is widely deployed now (and a dep on newer versions of Portage), so SHA512 is easily available. - RIPEMD160 was broken, so drop it as well. - Add WHIRLPOOL algorithm as it's not vulnerable to the same decomposition analysis introduced by Wang et al. - Add more detail to the migration plan. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #1.2: glep-0059.txt --] [-- Type: text/plain, Size: 8754 bytes --] GLEP: 59 Title: Manifest2 hash policies and security implications Version: $Revision: 1.6 $ Last-Modified: $Date: 2010/01/31 09:55:43 $ Author: Robin Hugh Johnson <robbat2@gentoo.org>, Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 44 Created: October 2006 Updated: November 2007, June 2008, July 2008, October 2008, January 2010 Updates: 44 Post-History: December 2009, January 2010 Abstract ======== While Manifest2 format allows multiple hashes, the question of which checksums should be present, why, and the security implications of such have never been resolved. This GLEP covers all of these issues, and makes recommendations as to how to handle checksums both now, and in future. Motivation ========== This GLEP is being written as part of the work on signing the Portage tree, but is only tangentially related to the actual signing of Manifests. Checksums present one possible weak point in the overall security of the tree - and a comprehensive security plan is needed. This GLEP is not mandatory for the tree-signing specification, but instead aims to improve the security of the hashes used in Manifest2. As such, it is also able to stand on it's own. Specification ============= The bad news ------------ First of all, I'd like to cover the bad news in checksum security. A much discussed point, as been the simple question: What is the security of multiple independent checksums on the same data? The most common position (and indeed the one previously held by myself), is that multiple checksums would be an increase in security, but we could not provably quantify the amount of security this added. The really bad news, is that this position is completely and utterly wrong. Many of you will be aghast at this. There is extremely little added security in multiple checksums as noted by Joux [J04]. For any set of checksums, the actual strength lies in that of the strongest checksum. Wang et al [W04] extended Joux's [J04] work on SHA-0 to cover MD4, MD5, HAVAL-128 and RIPEMD families of hashes. How fast can MD5 be broken? --------------------------- For a general collision, not a pre-image attack, since the announcement by Wang et al [W04], the time required to break MD5 has been massively reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to less than in two years, to 17 seconds [K06a]. 08/2004 - 1 hour, IBM pSeries 690 (32x 1.7Ghz POWER4+) = 54.4 GHz-Hours 03/2005 - 8 hours, Pentium-M 1.6Ghz = 12.8 Ghz-Hours 11/2005 - 5 hours, Pentium-4 1.7Ghz = 8.5 Ghz-Hours 03/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours 04/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours If we accept a factor of 800x as a sample of how much faster a checksum may be broken over the course of 2 years (MD5 using the above data is >2000x), then existing checksums do not stand a significant chance of survival in the future. We should thus accept that whatever checksums we are using today, will be broken in the near future, and plan as best as possible. (A brief review [H04] of the SHA1 attacks indicates an improvement of ~600x in the same timespan). And for those that claim implementation of these procedures is not yet feasible, see [K06b] for an application that can produce two self-extracting EXE files, with identical MD5s, and whatever payload you want. The good news ------------- Of the checksums presently used by Manifest2 (SHA1, SHA256, RIPEMD160), one stands close to being completely broken: SHA1; and another is significantly weakened: RIPEMD160. The SHA2 series has suffered some attacks, but still remains reasonably solid [G07],[K08]. To reduce the potential for future problems and any single checksum break leading to a rapid decrease in security, we should incorporate the strongest hash available from each family of checksums, and be prepared to retire old checksums actively, unless there is a overriding reason to keep a specific checksum, such as part of a migration plan. What should be done ------------------- Portage should always try to verify all supported hashes that are available in a Manifest2, starting with the strongest ones as maintained by a preference list. Over time, the weaker checksums should be removed from Manifest2 files, once all old Portage installations have had sufficient time to upgrade. We should be prepared to add stronger checksums wherever possible, and to remove those that have been defeated. As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms. In future, as stream-based checksums are developed (in response to the development by NIST [AHS]), they should be considered and used. The SHA512 algorithm is available in Python 2.5, which has been a dependency of Portage since approximately Python 2.1.6.13. The WHIRLPOOL checksum is not available within the PyCrypto library or hashlib that is part of Python 2.5, but there are multiple alternative Python implementations available, ranging from pure Python to C-based (python-mhash). The existence unsupported hash is not considered to be a failure unless no supported hashes are available for a given Manifest entry. Checksum depreciation timing ---------------------------- For the current Portage, both SHA1 and RIPEMD160 should be immediately removed, as they present no advantages over the already present SHA256. SHA256 cannot be replaced immediately with SHA512, as existing Portage versions need at least one supported algorithm present (SHA256 support was added in June 2006), so it must be retained for some while. Immediately: - Add WHIRLPOOL and SHA512. - Remove SHA1 and RIPEMD160. After the majority of Portage installations include SHA512 support: - Remove SHA256. Backwards Compatibility ======================= Old versions of Portage may support and expect only specific checksums. This is accounted for in the checksum depreciation discussion. References ========== [AHS] NIST (2007). "NIST's Plan for New Cryptographic Hash Functions", (Advanced Hash Standard). http://csrc.nist.gov/pki/HashWorkshop/ [BOBO06] Boneh, D. and Boyen, X. (2006). "On the Impossibility of Efficiently Combining Collision Resistant Hash Functions"; Proceedings of CRYPTO 2006, Dwork, C. (Ed.); Lecture Notes in Computer Science 4117, pp. 570-583. Available online from: http://crypto.stanford.edu/~dabo/abstracts/hashing.html [H04] Hawkes, P. and Paddon, M. and Rose, G. (2004). "On Corrective Patterns for the SHA-2 Family". CRYPTO 2004 Cryptology ePrint Archive, Report 2004/204. Available online from: http://eprint.iacr.org/2004/207.pdf [J04] Joux, Antoie. (2004). "Multicollisions in Iterated Hash Functions - Application to Cascaded Constructions;" Proceedings of CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer Science 3152, pp. 306-316. Available online from: http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf [K06a] Klima, V. (2006). "Tunnels in Hash Functions: MD5 Collisions Within a Minute". Cryptology ePrint Archive, Report 2006/105. Available online from: http://eprint.iacr.org/2006/105.pdf [K06b] Klima, V. (2006). "Note and links to high-speed MD5 collision proof of concept tools". Available online from: http://cryptography.hyperlink.cz/2006/trick.txt [K08] Klima, V. (2008). "On Collisions of Hash Functions Turbo SHA-2". Cryptology ePrint Archive, Report 2008/003. Available online from: http://eprint.iacr.org/2008/003.pdf [G07] Gligoroski, D. and Knapskog, S.J. (2007). "Turbo SHA-2". Cryptology ePrint Archive, Report 2007/403. Available online from: http://eprint.iacr.org/2007/403.pdf [W04] Wang, X. et al: "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", rump session, CRYPTO 2004, Cryptology ePrint Archive, Report 2004/199, first version (August 16, 2004), second version (August 17, 2004). Available online from: http://eprint.iacr.org/2004/199.pdf Thanks to ========= I'd like to thank the following folks, in no specific order: - Ciaran McCreesh (ciaranm) - for pointing out the Joux (2004) paper, and also being stubborn enough in not accepting a partial solution. - Marius Mauch (genone), Zac Medico (zmedico) and Brian Harring (ferringb): for being knowledgeable about the Portage Manifest2 codebase. Copyright ========= Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0. vim: tw=72 ts=2 expandtab: [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP59 - Manifest2 hashes 2010-01-31 9:57 ` [gentoo-dev] GLEP59 - Manifest2 hashes Robin H. Johnson @ 2010-02-01 5:05 ` Robin H. Johnson 2010-02-01 8:23 ` Doug Goldstein 1 sibling, 0 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-02-01 5:05 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 212 bytes --] Patches for Portage attached. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #1.2: portage-r15309-add-sha512-whirlpool.patch --] [-- Type: text/plain, Size: 54631 bytes --] diff -Nuarp trunk.orig/pym/portage/checksum.py trunk/pym/portage/checksum.py --- trunk.orig/pym/portage/checksum.py 2010-02-01 04:59:27.000000000 +0000 +++ trunk/pym/portage/checksum.py 2010-02-01 04:57:25.000000000 +0000 @@ -21,7 +21,7 @@ except ImportError: hashfunc_map = {} hashorigin_map = {} -def _generate_hash_function(hashtype, hashobject, origin="unknown"): +def _generate_hash_function(hashtype, hashobject, origin="unknown", hashobjectargs=None): def pyhash(filename): """ Run a checksum against a file. @@ -35,7 +35,11 @@ def _generate_hash_function(hashtype, ha blocksize = HASHING_BLOCKSIZE data = f.read(blocksize) size = 0 - checksum = hashobject() + if hashobjectargs is None: + checksum = hashobject() + else: + checksum = hashobject(hashobjectargs) + while data: checksum.update(data) size = size + len(data) @@ -65,6 +69,10 @@ except ImportError: sha1hash = _generate_hash_function("SHA1", _new_sha1, origin="internal") +# Bundled WHIRLPOOL implementation +from portage.whirlpool import new as _new_whirlpool +whirlpoolhash = _generate_hash_function("WHIRLPOOL", _new_whirlpool, origin="bundled") + # Use pycrypto when available, prefer it over the internal fallbacks try: from Crypto.Hash import SHA256, RIPEMD @@ -81,6 +89,7 @@ try: md5hash = _generate_hash_function("MD5", hashlib.md5, origin="hashlib") sha1hash = _generate_hash_function("SHA1", hashlib.sha1, origin="hashlib") sha256hash = _generate_hash_function("SHA256", hashlib.sha256, origin="hashlib") + sha512hash = _generate_hash_function("SHA512", hashlib.sha512, origin="hashlib") try: hashlib.new('ripemd160') except ValueError: @@ -92,6 +101,17 @@ try: except ImportError as e: pass +# Try to use mhash if available +try: + import mhash + md5hash = _generate_hash_function("MD5", mhash.MHASH, origin="mhash", hashobjectargs=mhash.MHASH_MD5) + sha1hash = _generate_hash_function("SHA1", mhash.MHASH, origin="mhash", hashobjectargs=mhash.MHASH_SHA1) + sha256hash = _generate_hash_function("SHA256", mhash.MHASH, origin="mhash", hashobjectargs=mhash.MHASH_SHA256) + sha512hash = _generate_hash_function("SHA512", mhash.MHASH, origin="mhash", hashobjectargs=mhash.MHASH_SHA512) + rmd160hash = _generate_hash_function("RMD160", mhash.MHASH, origin="mhash", hashobjectargs=mhash.MHASH_RIPEMD160) + whirlpoolhash = _generate_hash_function("WHIRLPOOL", mhash.MHASH, origin="mhash", hashobjectargs=mhash.MHASH_WHIRLPOOL) +except ImportError as e: + pass # Use python-fchksum if available, prefer it over all other MD5 implementations try: diff -Nuarp --exclude const.py trunk.orig/pym/portage/whirlpool.py trunk/pym/portage/whirlpool.py --- trunk.orig/pym/portage/whirlpool.py 1970-01-01 00:00:00.000000000 +0000 +++ trunk/pym/portage/whirlpool.py 2010-02-01 05:01:39.000000000 +0000 @@ -0,0 +1,788 @@ +## whirlpool.py - pure Python implementation of the Whirlpool algorithm. +## Bjorn Edstrom <be@bjrn.se> 16 december 2007. +## +## Copyrights +## ========== +## +## This code is based on the reference implementation by +## Paulo S.L.M. Barreto and Vincent Rijmen. The reference implementation +## is placed in the public domain but has the following headers: +## +## * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS +## * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +## * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +## * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE +## * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +## * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +## * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR +## * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, +## * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE +## * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, +## * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +## * +## */ +## /* The code contained in this file (Whirlpool.c) is in the public domain. */ +## +## This Python implementation is therefore also placed in the public domain. + +#block_size = 64 +digest_size = 64 +digestsize = 64 + +class Whirlpool: + """Return a new Whirlpool object. An optional string argument + may be provided; if present, this string will be automatically + hashed.""" + def __init__(self, arg=None): + self.ctx = WhirlpoolStruct() + if arg: + self.update(arg) + self.digest_status = 0 + + def update(self, arg): + """update(arg)""" + WhirlpoolAdd(arg, len(arg)*8, self.ctx) + self.digest_status = 0 + + def digest(self): + """digest()""" + if self.digest_status == 0: + self.dig = WhirlpoolFinalize(self.ctx) + self.digest_status = 1 + return self.dig + + def hexdigest(self): + """hexdigest()""" + dig = self.digest() + tempstr = '' + for d in dig: + xxx = '%02x' % (ord(d)) + tempstr = tempstr + xxx + return tempstr + + def copy(self): + """copy()""" + import copy + return copy.deepcopy(self) + + +def new(init=None): + """Return a new Whirlpool object. An optional string argument + may be provided; if present, this string will be automatically + hashed.""" + return Whirlpool(init) + +# +# Private. +# + +R = 10 + +C0 = [ +0x18186018c07830d8, 0x23238c2305af4626, 0xc6c63fc67ef991b8, 0xe8e887e8136fcdfb, +0x878726874ca113cb, 0xb8b8dab8a9626d11, 0x0101040108050209, 0x4f4f214f426e9e0d, +0x3636d836adee6c9b, 0xa6a6a2a6590451ff, 0xd2d26fd2debdb90c, 0xf5f5f3f5fb06f70e, +0x7979f979ef80f296, 0x6f6fa16f5fcede30, 0x91917e91fcef3f6d, 0x52525552aa07a4f8, +0x60609d6027fdc047, 0xbcbccabc89766535, 0x9b9b569baccd2b37, 0x8e8e028e048c018a, +0xa3a3b6a371155bd2, 0x0c0c300c603c186c, 0x7b7bf17bff8af684, 0x3535d435b5e16a80, +0x1d1d741de8693af5, 0xe0e0a7e05347ddb3, 0xd7d77bd7f6acb321, 0xc2c22fc25eed999c, +0x2e2eb82e6d965c43, 0x4b4b314b627a9629, 0xfefedffea321e15d, 0x575741578216aed5, +0x15155415a8412abd, 0x7777c1779fb6eee8, 0x3737dc37a5eb6e92, 0xe5e5b3e57b56d79e, +0x9f9f469f8cd92313, 0xf0f0e7f0d317fd23, 0x4a4a354a6a7f9420, 0xdada4fda9e95a944, +0x58587d58fa25b0a2, 0xc9c903c906ca8fcf, 0x2929a429558d527c, 0x0a0a280a5022145a, +0xb1b1feb1e14f7f50, 0xa0a0baa0691a5dc9, 0x6b6bb16b7fdad614, 0x85852e855cab17d9, +0xbdbdcebd8173673c, 0x5d5d695dd234ba8f, 0x1010401080502090, 0xf4f4f7f4f303f507, +0xcbcb0bcb16c08bdd, 0x3e3ef83eedc67cd3, 0x0505140528110a2d, 0x676781671fe6ce78, +0xe4e4b7e47353d597, 0x27279c2725bb4e02, 0x4141194132588273, 0x8b8b168b2c9d0ba7, +0xa7a7a6a7510153f6, 0x7d7de97dcf94fab2, 0x95956e95dcfb3749, 0xd8d847d88e9fad56, +0xfbfbcbfb8b30eb70, 0xeeee9fee2371c1cd, 0x7c7ced7cc791f8bb, 0x6666856617e3cc71, +0xdddd53dda68ea77b, 0x17175c17b84b2eaf, 0x4747014702468e45, 0x9e9e429e84dc211a, +0xcaca0fca1ec589d4, 0x2d2db42d75995a58, 0xbfbfc6bf9179632e, 0x07071c07381b0e3f, +0xadad8ead012347ac, 0x5a5a755aea2fb4b0, 0x838336836cb51bef, 0x3333cc3385ff66b6, +0x636391633ff2c65c, 0x02020802100a0412, 0xaaaa92aa39384993, 0x7171d971afa8e2de, +0xc8c807c80ecf8dc6, 0x19196419c87d32d1, 0x494939497270923b, 0xd9d943d9869aaf5f, +0xf2f2eff2c31df931, 0xe3e3abe34b48dba8, 0x5b5b715be22ab6b9, 0x88881a8834920dbc, +0x9a9a529aa4c8293e, 0x262698262dbe4c0b, 0x3232c8328dfa64bf, 0xb0b0fab0e94a7d59, +0xe9e983e91b6acff2, 0x0f0f3c0f78331e77, 0xd5d573d5e6a6b733, 0x80803a8074ba1df4, +0xbebec2be997c6127, 0xcdcd13cd26de87eb, 0x3434d034bde46889, 0x48483d487a759032, +0xffffdbffab24e354, 0x7a7af57af78ff48d, 0x90907a90f4ea3d64, 0x5f5f615fc23ebe9d, +0x202080201da0403d, 0x6868bd6867d5d00f, 0x1a1a681ad07234ca, 0xaeae82ae192c41b7, +0xb4b4eab4c95e757d, 0x54544d549a19a8ce, 0x93937693ece53b7f, 0x222288220daa442f, +0x64648d6407e9c863, 0xf1f1e3f1db12ff2a, 0x7373d173bfa2e6cc, 0x12124812905a2482, +0x40401d403a5d807a, 0x0808200840281048, 0xc3c32bc356e89b95, 0xecec97ec337bc5df, +0xdbdb4bdb9690ab4d, 0xa1a1bea1611f5fc0, 0x8d8d0e8d1c830791, 0x3d3df43df5c97ac8, +0x97976697ccf1335b, 0x0000000000000000, 0xcfcf1bcf36d483f9, 0x2b2bac2b4587566e, +0x7676c57697b3ece1, 0x8282328264b019e6, 0xd6d67fd6fea9b128, 0x1b1b6c1bd87736c3, +0xb5b5eeb5c15b7774, 0xafaf86af112943be, 0x6a6ab56a77dfd41d, 0x50505d50ba0da0ea, +0x45450945124c8a57, 0xf3f3ebf3cb18fb38, 0x3030c0309df060ad, 0xefef9bef2b74c3c4, +0x3f3ffc3fe5c37eda, 0x55554955921caac7, 0xa2a2b2a2791059db, 0xeaea8fea0365c9e9, +0x656589650fecca6a, 0xbabad2bab9686903, 0x2f2fbc2f65935e4a, 0xc0c027c04ee79d8e, +0xdede5fdebe81a160, 0x1c1c701ce06c38fc, 0xfdfdd3fdbb2ee746, 0x4d4d294d52649a1f, +0x92927292e4e03976, 0x7575c9758fbceafa, 0x06061806301e0c36, 0x8a8a128a249809ae, +0xb2b2f2b2f940794b, 0xe6e6bfe66359d185, 0x0e0e380e70361c7e, 0x1f1f7c1ff8633ee7, +0x6262956237f7c455, 0xd4d477d4eea3b53a, 0xa8a89aa829324d81, 0x96966296c4f43152, +0xf9f9c3f99b3aef62, 0xc5c533c566f697a3, 0x2525942535b14a10, 0x59597959f220b2ab, +0x84842a8454ae15d0, 0x7272d572b7a7e4c5, 0x3939e439d5dd72ec, 0x4c4c2d4c5a619816, +0x5e5e655eca3bbc94, 0x7878fd78e785f09f, 0x3838e038ddd870e5, 0x8c8c0a8c14860598, +0xd1d163d1c6b2bf17, 0xa5a5aea5410b57e4, 0xe2e2afe2434dd9a1, 0x616199612ff8c24e, +0xb3b3f6b3f1457b42, 0x2121842115a54234, 0x9c9c4a9c94d62508, 0x1e1e781ef0663cee, +0x4343114322528661, 0xc7c73bc776fc93b1, 0xfcfcd7fcb32be54f, 0x0404100420140824, +0x51515951b208a2e3, 0x99995e99bcc72f25, 0x6d6da96d4fc4da22, 0x0d0d340d68391a65, +0xfafacffa8335e979, 0xdfdf5bdfb684a369, 0x7e7ee57ed79bfca9, 0x242490243db44819, +0x3b3bec3bc5d776fe, 0xabab96ab313d4b9a, 0xcece1fce3ed181f0, 0x1111441188552299, +0x8f8f068f0c890383, 0x4e4e254e4a6b9c04, 0xb7b7e6b7d1517366, 0xebeb8beb0b60cbe0, +0x3c3cf03cfdcc78c1, 0x81813e817cbf1ffd, 0x94946a94d4fe3540, 0xf7f7fbf7eb0cf31c, +0xb9b9deb9a1676f18, 0x13134c13985f268b, 0x2c2cb02c7d9c5851, 0xd3d36bd3d6b8bb05, +0xe7e7bbe76b5cd38c, 0x6e6ea56e57cbdc39, 0xc4c437c46ef395aa, 0x03030c03180f061b, +0x565645568a13acdc, 0x44440d441a49885e, 0x7f7fe17fdf9efea0, 0xa9a99ea921374f88, +0x2a2aa82a4d825467, 0xbbbbd6bbb16d6b0a, 0xc1c123c146e29f87, 0x53535153a202a6f1, +0xdcdc57dcae8ba572, 0x0b0b2c0b58271653, 0x9d9d4e9d9cd32701, 0x6c6cad6c47c1d82b, +0x3131c43195f562a4, 0x7474cd7487b9e8f3, 0xf6f6fff6e309f115, 0x464605460a438c4c, +0xacac8aac092645a5, 0x89891e893c970fb5, 0x14145014a04428b4, 0xe1e1a3e15b42dfba, +0x16165816b04e2ca6, 0x3a3ae83acdd274f7, 0x6969b9696fd0d206, 0x09092409482d1241, +0x7070dd70a7ade0d7, 0xb6b6e2b6d954716f, 0xd0d067d0ceb7bd1e, 0xeded93ed3b7ec7d6, +0xcccc17cc2edb85e2, 0x424215422a578468, 0x98985a98b4c22d2c, 0xa4a4aaa4490e55ed, +0x2828a0285d885075, 0x5c5c6d5cda31b886, 0xf8f8c7f8933fed6b, 0x8686228644a411c2, +] +C1 = [ +0xd818186018c07830, 0x2623238c2305af46, 0xb8c6c63fc67ef991, 0xfbe8e887e8136fcd, +0xcb878726874ca113, 0x11b8b8dab8a9626d, 0x0901010401080502, 0x0d4f4f214f426e9e, +0x9b3636d836adee6c, 0xffa6a6a2a6590451, 0x0cd2d26fd2debdb9, 0x0ef5f5f3f5fb06f7, +0x967979f979ef80f2, 0x306f6fa16f5fcede, 0x6d91917e91fcef3f, 0xf852525552aa07a4, +0x4760609d6027fdc0, 0x35bcbccabc897665, 0x379b9b569baccd2b, 0x8a8e8e028e048c01, +0xd2a3a3b6a371155b, 0x6c0c0c300c603c18, 0x847b7bf17bff8af6, 0x803535d435b5e16a, +0xf51d1d741de8693a, 0xb3e0e0a7e05347dd, 0x21d7d77bd7f6acb3, 0x9cc2c22fc25eed99, +0x432e2eb82e6d965c, 0x294b4b314b627a96, 0x5dfefedffea321e1, 0xd5575741578216ae, +0xbd15155415a8412a, 0xe87777c1779fb6ee, 0x923737dc37a5eb6e, 0x9ee5e5b3e57b56d7, +0x139f9f469f8cd923, 0x23f0f0e7f0d317fd, 0x204a4a354a6a7f94, 0x44dada4fda9e95a9, +0xa258587d58fa25b0, 0xcfc9c903c906ca8f, 0x7c2929a429558d52, 0x5a0a0a280a502214, +0x50b1b1feb1e14f7f, 0xc9a0a0baa0691a5d, 0x146b6bb16b7fdad6, 0xd985852e855cab17, +0x3cbdbdcebd817367, 0x8f5d5d695dd234ba, 0x9010104010805020, 0x07f4f4f7f4f303f5, +0xddcbcb0bcb16c08b, 0xd33e3ef83eedc67c, 0x2d0505140528110a, 0x78676781671fe6ce, +0x97e4e4b7e47353d5, 0x0227279c2725bb4e, 0x7341411941325882, 0xa78b8b168b2c9d0b, +0xf6a7a7a6a7510153, 0xb27d7de97dcf94fa, 0x4995956e95dcfb37, 0x56d8d847d88e9fad, +0x70fbfbcbfb8b30eb, 0xcdeeee9fee2371c1, 0xbb7c7ced7cc791f8, 0x716666856617e3cc, +0x7bdddd53dda68ea7, 0xaf17175c17b84b2e, 0x454747014702468e, 0x1a9e9e429e84dc21, +0xd4caca0fca1ec589, 0x582d2db42d75995a, 0x2ebfbfc6bf917963, 0x3f07071c07381b0e, +0xacadad8ead012347, 0xb05a5a755aea2fb4, 0xef838336836cb51b, 0xb63333cc3385ff66, +0x5c636391633ff2c6, 0x1202020802100a04, 0x93aaaa92aa393849, 0xde7171d971afa8e2, +0xc6c8c807c80ecf8d, 0xd119196419c87d32, 0x3b49493949727092, 0x5fd9d943d9869aaf, +0x31f2f2eff2c31df9, 0xa8e3e3abe34b48db, 0xb95b5b715be22ab6, 0xbc88881a8834920d, +0x3e9a9a529aa4c829, 0x0b262698262dbe4c, 0xbf3232c8328dfa64, 0x59b0b0fab0e94a7d, +0xf2e9e983e91b6acf, 0x770f0f3c0f78331e, 0x33d5d573d5e6a6b7, 0xf480803a8074ba1d, +0x27bebec2be997c61, 0xebcdcd13cd26de87, 0x893434d034bde468, 0x3248483d487a7590, +0x54ffffdbffab24e3, 0x8d7a7af57af78ff4, 0x6490907a90f4ea3d, 0x9d5f5f615fc23ebe, +0x3d202080201da040, 0x0f6868bd6867d5d0, 0xca1a1a681ad07234, 0xb7aeae82ae192c41, +0x7db4b4eab4c95e75, 0xce54544d549a19a8, 0x7f93937693ece53b, 0x2f222288220daa44, +0x6364648d6407e9c8, 0x2af1f1e3f1db12ff, 0xcc7373d173bfa2e6, 0x8212124812905a24, +0x7a40401d403a5d80, 0x4808082008402810, 0x95c3c32bc356e89b, 0xdfecec97ec337bc5, +0x4ddbdb4bdb9690ab, 0xc0a1a1bea1611f5f, 0x918d8d0e8d1c8307, 0xc83d3df43df5c97a, +0x5b97976697ccf133, 0x0000000000000000, 0xf9cfcf1bcf36d483, 0x6e2b2bac2b458756, +0xe17676c57697b3ec, 0xe68282328264b019, 0x28d6d67fd6fea9b1, 0xc31b1b6c1bd87736, +0x74b5b5eeb5c15b77, 0xbeafaf86af112943, 0x1d6a6ab56a77dfd4, 0xea50505d50ba0da0, +0x5745450945124c8a, 0x38f3f3ebf3cb18fb, 0xad3030c0309df060, 0xc4efef9bef2b74c3, +0xda3f3ffc3fe5c37e, 0xc755554955921caa, 0xdba2a2b2a2791059, 0xe9eaea8fea0365c9, +0x6a656589650fecca, 0x03babad2bab96869, 0x4a2f2fbc2f65935e, 0x8ec0c027c04ee79d, +0x60dede5fdebe81a1, 0xfc1c1c701ce06c38, 0x46fdfdd3fdbb2ee7, 0x1f4d4d294d52649a, +0x7692927292e4e039, 0xfa7575c9758fbcea, 0x3606061806301e0c, 0xae8a8a128a249809, +0x4bb2b2f2b2f94079, 0x85e6e6bfe66359d1, 0x7e0e0e380e70361c, 0xe71f1f7c1ff8633e, +0x556262956237f7c4, 0x3ad4d477d4eea3b5, 0x81a8a89aa829324d, 0x5296966296c4f431, +0x62f9f9c3f99b3aef, 0xa3c5c533c566f697, 0x102525942535b14a, 0xab59597959f220b2, +0xd084842a8454ae15, 0xc57272d572b7a7e4, 0xec3939e439d5dd72, 0x164c4c2d4c5a6198, +0x945e5e655eca3bbc, 0x9f7878fd78e785f0, 0xe53838e038ddd870, 0x988c8c0a8c148605, +0x17d1d163d1c6b2bf, 0xe4a5a5aea5410b57, 0xa1e2e2afe2434dd9, 0x4e616199612ff8c2, +0x42b3b3f6b3f1457b, 0x342121842115a542, 0x089c9c4a9c94d625, 0xee1e1e781ef0663c, +0x6143431143225286, 0xb1c7c73bc776fc93, 0x4ffcfcd7fcb32be5, 0x2404041004201408, +0xe351515951b208a2, 0x2599995e99bcc72f, 0x226d6da96d4fc4da, 0x650d0d340d68391a, +0x79fafacffa8335e9, 0x69dfdf5bdfb684a3, 0xa97e7ee57ed79bfc, 0x19242490243db448, +0xfe3b3bec3bc5d776, 0x9aabab96ab313d4b, 0xf0cece1fce3ed181, 0x9911114411885522, +0x838f8f068f0c8903, 0x044e4e254e4a6b9c, 0x66b7b7e6b7d15173, 0xe0ebeb8beb0b60cb, +0xc13c3cf03cfdcc78, 0xfd81813e817cbf1f, 0x4094946a94d4fe35, 0x1cf7f7fbf7eb0cf3, +0x18b9b9deb9a1676f, 0x8b13134c13985f26, 0x512c2cb02c7d9c58, 0x05d3d36bd3d6b8bb, +0x8ce7e7bbe76b5cd3, 0x396e6ea56e57cbdc, 0xaac4c437c46ef395, 0x1b03030c03180f06, +0xdc565645568a13ac, 0x5e44440d441a4988, 0xa07f7fe17fdf9efe, 0x88a9a99ea921374f, +0x672a2aa82a4d8254, 0x0abbbbd6bbb16d6b, 0x87c1c123c146e29f, 0xf153535153a202a6, +0x72dcdc57dcae8ba5, 0x530b0b2c0b582716, 0x019d9d4e9d9cd327, 0x2b6c6cad6c47c1d8, +0xa43131c43195f562, 0xf37474cd7487b9e8, 0x15f6f6fff6e309f1, 0x4c464605460a438c, +0xa5acac8aac092645, 0xb589891e893c970f, 0xb414145014a04428, 0xbae1e1a3e15b42df, +0xa616165816b04e2c, 0xf73a3ae83acdd274, 0x066969b9696fd0d2, 0x4109092409482d12, +0xd77070dd70a7ade0, 0x6fb6b6e2b6d95471, 0x1ed0d067d0ceb7bd, 0xd6eded93ed3b7ec7, +0xe2cccc17cc2edb85, 0x68424215422a5784, 0x2c98985a98b4c22d, 0xeda4a4aaa4490e55, +0x752828a0285d8850, 0x865c5c6d5cda31b8, 0x6bf8f8c7f8933fed, 0xc28686228644a411, +] +C2 = [ +0x30d818186018c078, 0x462623238c2305af, 0x91b8c6c63fc67ef9, 0xcdfbe8e887e8136f, +0x13cb878726874ca1, 0x6d11b8b8dab8a962, 0x0209010104010805, 0x9e0d4f4f214f426e, +0x6c9b3636d836adee, 0x51ffa6a6a2a65904, 0xb90cd2d26fd2debd, 0xf70ef5f5f3f5fb06, +0xf2967979f979ef80, 0xde306f6fa16f5fce, 0x3f6d91917e91fcef, 0xa4f852525552aa07, +0xc04760609d6027fd, 0x6535bcbccabc8976, 0x2b379b9b569baccd, 0x018a8e8e028e048c, +0x5bd2a3a3b6a37115, 0x186c0c0c300c603c, 0xf6847b7bf17bff8a, 0x6a803535d435b5e1, +0x3af51d1d741de869, 0xddb3e0e0a7e05347, 0xb321d7d77bd7f6ac, 0x999cc2c22fc25eed, +0x5c432e2eb82e6d96, 0x96294b4b314b627a, 0xe15dfefedffea321, 0xaed5575741578216, +0x2abd15155415a841, 0xeee87777c1779fb6, 0x6e923737dc37a5eb, 0xd79ee5e5b3e57b56, +0x23139f9f469f8cd9, 0xfd23f0f0e7f0d317, 0x94204a4a354a6a7f, 0xa944dada4fda9e95, +0xb0a258587d58fa25, 0x8fcfc9c903c906ca, 0x527c2929a429558d, 0x145a0a0a280a5022, +0x7f50b1b1feb1e14f, 0x5dc9a0a0baa0691a, 0xd6146b6bb16b7fda, 0x17d985852e855cab, +0x673cbdbdcebd8173, 0xba8f5d5d695dd234, 0x2090101040108050, 0xf507f4f4f7f4f303, +0x8bddcbcb0bcb16c0, 0x7cd33e3ef83eedc6, 0x0a2d050514052811, 0xce78676781671fe6, +0xd597e4e4b7e47353, 0x4e0227279c2725bb, 0x8273414119413258, 0x0ba78b8b168b2c9d, +0x53f6a7a7a6a75101, 0xfab27d7de97dcf94, 0x374995956e95dcfb, 0xad56d8d847d88e9f, +0xeb70fbfbcbfb8b30, 0xc1cdeeee9fee2371, 0xf8bb7c7ced7cc791, 0xcc716666856617e3, +0xa77bdddd53dda68e, 0x2eaf17175c17b84b, 0x8e45474701470246, 0x211a9e9e429e84dc, +0x89d4caca0fca1ec5, 0x5a582d2db42d7599, 0x632ebfbfc6bf9179, 0x0e3f07071c07381b, +0x47acadad8ead0123, 0xb4b05a5a755aea2f, 0x1bef838336836cb5, 0x66b63333cc3385ff, +0xc65c636391633ff2, 0x041202020802100a, 0x4993aaaa92aa3938, 0xe2de7171d971afa8, +0x8dc6c8c807c80ecf, 0x32d119196419c87d, 0x923b494939497270, 0xaf5fd9d943d9869a, +0xf931f2f2eff2c31d, 0xdba8e3e3abe34b48, 0xb6b95b5b715be22a, 0x0dbc88881a883492, +0x293e9a9a529aa4c8, 0x4c0b262698262dbe, 0x64bf3232c8328dfa, 0x7d59b0b0fab0e94a, +0xcff2e9e983e91b6a, 0x1e770f0f3c0f7833, 0xb733d5d573d5e6a6, 0x1df480803a8074ba, +0x6127bebec2be997c, 0x87ebcdcd13cd26de, 0x68893434d034bde4, 0x903248483d487a75, +0xe354ffffdbffab24, 0xf48d7a7af57af78f, 0x3d6490907a90f4ea, 0xbe9d5f5f615fc23e, +0x403d202080201da0, 0xd00f6868bd6867d5, 0x34ca1a1a681ad072, 0x41b7aeae82ae192c, +0x757db4b4eab4c95e, 0xa8ce54544d549a19, 0x3b7f93937693ece5, 0x442f222288220daa, +0xc86364648d6407e9, 0xff2af1f1e3f1db12, 0xe6cc7373d173bfa2, 0x248212124812905a, +0x807a40401d403a5d, 0x1048080820084028, 0x9b95c3c32bc356e8, 0xc5dfecec97ec337b, +0xab4ddbdb4bdb9690, 0x5fc0a1a1bea1611f, 0x07918d8d0e8d1c83, 0x7ac83d3df43df5c9, +0x335b97976697ccf1, 0x0000000000000000, 0x83f9cfcf1bcf36d4, 0x566e2b2bac2b4587, +0xece17676c57697b3, 0x19e68282328264b0, 0xb128d6d67fd6fea9, 0x36c31b1b6c1bd877, +0x7774b5b5eeb5c15b, 0x43beafaf86af1129, 0xd41d6a6ab56a77df, 0xa0ea50505d50ba0d, +0x8a5745450945124c, 0xfb38f3f3ebf3cb18, 0x60ad3030c0309df0, 0xc3c4efef9bef2b74, +0x7eda3f3ffc3fe5c3, 0xaac755554955921c, 0x59dba2a2b2a27910, 0xc9e9eaea8fea0365, +0xca6a656589650fec, 0x6903babad2bab968, 0x5e4a2f2fbc2f6593, 0x9d8ec0c027c04ee7, +0xa160dede5fdebe81, 0x38fc1c1c701ce06c, 0xe746fdfdd3fdbb2e, 0x9a1f4d4d294d5264, +0x397692927292e4e0, 0xeafa7575c9758fbc, 0x0c3606061806301e, 0x09ae8a8a128a2498, +0x794bb2b2f2b2f940, 0xd185e6e6bfe66359, 0x1c7e0e0e380e7036, 0x3ee71f1f7c1ff863, +0xc4556262956237f7, 0xb53ad4d477d4eea3, 0x4d81a8a89aa82932, 0x315296966296c4f4, +0xef62f9f9c3f99b3a, 0x97a3c5c533c566f6, 0x4a102525942535b1, 0xb2ab59597959f220, +0x15d084842a8454ae, 0xe4c57272d572b7a7, 0x72ec3939e439d5dd, 0x98164c4c2d4c5a61, +0xbc945e5e655eca3b, 0xf09f7878fd78e785, 0x70e53838e038ddd8, 0x05988c8c0a8c1486, +0xbf17d1d163d1c6b2, 0x57e4a5a5aea5410b, 0xd9a1e2e2afe2434d, 0xc24e616199612ff8, +0x7b42b3b3f6b3f145, 0x42342121842115a5, 0x25089c9c4a9c94d6, 0x3cee1e1e781ef066, +0x8661434311432252, 0x93b1c7c73bc776fc, 0xe54ffcfcd7fcb32b, 0x0824040410042014, +0xa2e351515951b208, 0x2f2599995e99bcc7, 0xda226d6da96d4fc4, 0x1a650d0d340d6839, +0xe979fafacffa8335, 0xa369dfdf5bdfb684, 0xfca97e7ee57ed79b, 0x4819242490243db4, +0x76fe3b3bec3bc5d7, 0x4b9aabab96ab313d, 0x81f0cece1fce3ed1, 0x2299111144118855, +0x03838f8f068f0c89, 0x9c044e4e254e4a6b, 0x7366b7b7e6b7d151, 0xcbe0ebeb8beb0b60, +0x78c13c3cf03cfdcc, 0x1ffd81813e817cbf, 0x354094946a94d4fe, 0xf31cf7f7fbf7eb0c, +0x6f18b9b9deb9a167, 0x268b13134c13985f, 0x58512c2cb02c7d9c, 0xbb05d3d36bd3d6b8, +0xd38ce7e7bbe76b5c, 0xdc396e6ea56e57cb, 0x95aac4c437c46ef3, 0x061b03030c03180f, +0xacdc565645568a13, 0x885e44440d441a49, 0xfea07f7fe17fdf9e, 0x4f88a9a99ea92137, +0x54672a2aa82a4d82, 0x6b0abbbbd6bbb16d, 0x9f87c1c123c146e2, 0xa6f153535153a202, +0xa572dcdc57dcae8b, 0x16530b0b2c0b5827, 0x27019d9d4e9d9cd3, 0xd82b6c6cad6c47c1, +0x62a43131c43195f5, 0xe8f37474cd7487b9, 0xf115f6f6fff6e309, 0x8c4c464605460a43, +0x45a5acac8aac0926, 0x0fb589891e893c97, 0x28b414145014a044, 0xdfbae1e1a3e15b42, +0x2ca616165816b04e, 0x74f73a3ae83acdd2, 0xd2066969b9696fd0, 0x124109092409482d, +0xe0d77070dd70a7ad, 0x716fb6b6e2b6d954, 0xbd1ed0d067d0ceb7, 0xc7d6eded93ed3b7e, +0x85e2cccc17cc2edb, 0x8468424215422a57, 0x2d2c98985a98b4c2, 0x55eda4a4aaa4490e, +0x50752828a0285d88, 0xb8865c5c6d5cda31, 0xed6bf8f8c7f8933f, 0x11c28686228644a4, +] +C3 = [ +0x7830d818186018c0, 0xaf462623238c2305, 0xf991b8c6c63fc67e, 0x6fcdfbe8e887e813, +0xa113cb878726874c, 0x626d11b8b8dab8a9, 0x0502090101040108, 0x6e9e0d4f4f214f42, +0xee6c9b3636d836ad, 0x0451ffa6a6a2a659, 0xbdb90cd2d26fd2de, 0x06f70ef5f5f3f5fb, +0x80f2967979f979ef, 0xcede306f6fa16f5f, 0xef3f6d91917e91fc, 0x07a4f852525552aa, +0xfdc04760609d6027, 0x766535bcbccabc89, 0xcd2b379b9b569bac, 0x8c018a8e8e028e04, +0x155bd2a3a3b6a371, 0x3c186c0c0c300c60, 0x8af6847b7bf17bff, 0xe16a803535d435b5, +0x693af51d1d741de8, 0x47ddb3e0e0a7e053, 0xacb321d7d77bd7f6, 0xed999cc2c22fc25e, +0x965c432e2eb82e6d, 0x7a96294b4b314b62, 0x21e15dfefedffea3, 0x16aed55757415782, +0x412abd15155415a8, 0xb6eee87777c1779f, 0xeb6e923737dc37a5, 0x56d79ee5e5b3e57b, +0xd923139f9f469f8c, 0x17fd23f0f0e7f0d3, 0x7f94204a4a354a6a, 0x95a944dada4fda9e, +0x25b0a258587d58fa, 0xca8fcfc9c903c906, 0x8d527c2929a42955, 0x22145a0a0a280a50, +0x4f7f50b1b1feb1e1, 0x1a5dc9a0a0baa069, 0xdad6146b6bb16b7f, 0xab17d985852e855c, +0x73673cbdbdcebd81, 0x34ba8f5d5d695dd2, 0x5020901010401080, 0x03f507f4f4f7f4f3, +0xc08bddcbcb0bcb16, 0xc67cd33e3ef83eed, 0x110a2d0505140528, 0xe6ce78676781671f, +0x53d597e4e4b7e473, 0xbb4e0227279c2725, 0x5882734141194132, 0x9d0ba78b8b168b2c, +0x0153f6a7a7a6a751, 0x94fab27d7de97dcf, 0xfb374995956e95dc, 0x9fad56d8d847d88e, +0x30eb70fbfbcbfb8b, 0x71c1cdeeee9fee23, 0x91f8bb7c7ced7cc7, 0xe3cc716666856617, +0x8ea77bdddd53dda6, 0x4b2eaf17175c17b8, 0x468e454747014702, 0xdc211a9e9e429e84, +0xc589d4caca0fca1e, 0x995a582d2db42d75, 0x79632ebfbfc6bf91, 0x1b0e3f07071c0738, +0x2347acadad8ead01, 0x2fb4b05a5a755aea, 0xb51bef838336836c, 0xff66b63333cc3385, +0xf2c65c636391633f, 0x0a04120202080210, 0x384993aaaa92aa39, 0xa8e2de7171d971af, +0xcf8dc6c8c807c80e, 0x7d32d119196419c8, 0x70923b4949394972, 0x9aaf5fd9d943d986, +0x1df931f2f2eff2c3, 0x48dba8e3e3abe34b, 0x2ab6b95b5b715be2, 0x920dbc88881a8834, +0xc8293e9a9a529aa4, 0xbe4c0b262698262d, 0xfa64bf3232c8328d, 0x4a7d59b0b0fab0e9, +0x6acff2e9e983e91b, 0x331e770f0f3c0f78, 0xa6b733d5d573d5e6, 0xba1df480803a8074, +0x7c6127bebec2be99, 0xde87ebcdcd13cd26, 0xe468893434d034bd, 0x75903248483d487a, +0x24e354ffffdbffab, 0x8ff48d7a7af57af7, 0xea3d6490907a90f4, 0x3ebe9d5f5f615fc2, +0xa0403d202080201d, 0xd5d00f6868bd6867, 0x7234ca1a1a681ad0, 0x2c41b7aeae82ae19, +0x5e757db4b4eab4c9, 0x19a8ce54544d549a, 0xe53b7f93937693ec, 0xaa442f222288220d, +0xe9c86364648d6407, 0x12ff2af1f1e3f1db, 0xa2e6cc7373d173bf, 0x5a24821212481290, +0x5d807a40401d403a, 0x2810480808200840, 0xe89b95c3c32bc356, 0x7bc5dfecec97ec33, +0x90ab4ddbdb4bdb96, 0x1f5fc0a1a1bea161, 0x8307918d8d0e8d1c, 0xc97ac83d3df43df5, +0xf1335b97976697cc, 0x0000000000000000, 0xd483f9cfcf1bcf36, 0x87566e2b2bac2b45, +0xb3ece17676c57697, 0xb019e68282328264, 0xa9b128d6d67fd6fe, 0x7736c31b1b6c1bd8, +0x5b7774b5b5eeb5c1, 0x2943beafaf86af11, 0xdfd41d6a6ab56a77, 0x0da0ea50505d50ba, +0x4c8a574545094512, 0x18fb38f3f3ebf3cb, 0xf060ad3030c0309d, 0x74c3c4efef9bef2b, +0xc37eda3f3ffc3fe5, 0x1caac75555495592, 0x1059dba2a2b2a279, 0x65c9e9eaea8fea03, +0xecca6a656589650f, 0x686903babad2bab9, 0x935e4a2f2fbc2f65, 0xe79d8ec0c027c04e, +0x81a160dede5fdebe, 0x6c38fc1c1c701ce0, 0x2ee746fdfdd3fdbb, 0x649a1f4d4d294d52, +0xe0397692927292e4, 0xbceafa7575c9758f, 0x1e0c360606180630, 0x9809ae8a8a128a24, +0x40794bb2b2f2b2f9, 0x59d185e6e6bfe663, 0x361c7e0e0e380e70, 0x633ee71f1f7c1ff8, +0xf7c4556262956237, 0xa3b53ad4d477d4ee, 0x324d81a8a89aa829, 0xf4315296966296c4, +0x3aef62f9f9c3f99b, 0xf697a3c5c533c566, 0xb14a102525942535, 0x20b2ab59597959f2, +0xae15d084842a8454, 0xa7e4c57272d572b7, 0xdd72ec3939e439d5, 0x6198164c4c2d4c5a, +0x3bbc945e5e655eca, 0x85f09f7878fd78e7, 0xd870e53838e038dd, 0x8605988c8c0a8c14, +0xb2bf17d1d163d1c6, 0x0b57e4a5a5aea541, 0x4dd9a1e2e2afe243, 0xf8c24e616199612f, +0x457b42b3b3f6b3f1, 0xa542342121842115, 0xd625089c9c4a9c94, 0x663cee1e1e781ef0, +0x5286614343114322, 0xfc93b1c7c73bc776, 0x2be54ffcfcd7fcb3, 0x1408240404100420, +0x08a2e351515951b2, 0xc72f2599995e99bc, 0xc4da226d6da96d4f, 0x391a650d0d340d68, +0x35e979fafacffa83, 0x84a369dfdf5bdfb6, 0x9bfca97e7ee57ed7, 0xb44819242490243d, +0xd776fe3b3bec3bc5, 0x3d4b9aabab96ab31, 0xd181f0cece1fce3e, 0x5522991111441188, +0x8903838f8f068f0c, 0x6b9c044e4e254e4a, 0x517366b7b7e6b7d1, 0x60cbe0ebeb8beb0b, +0xcc78c13c3cf03cfd, 0xbf1ffd81813e817c, 0xfe354094946a94d4, 0x0cf31cf7f7fbf7eb, +0x676f18b9b9deb9a1, 0x5f268b13134c1398, 0x9c58512c2cb02c7d, 0xb8bb05d3d36bd3d6, +0x5cd38ce7e7bbe76b, 0xcbdc396e6ea56e57, 0xf395aac4c437c46e, 0x0f061b03030c0318, +0x13acdc565645568a, 0x49885e44440d441a, 0x9efea07f7fe17fdf, 0x374f88a9a99ea921, +0x8254672a2aa82a4d, 0x6d6b0abbbbd6bbb1, 0xe29f87c1c123c146, 0x02a6f153535153a2, +0x8ba572dcdc57dcae, 0x2716530b0b2c0b58, 0xd327019d9d4e9d9c, 0xc1d82b6c6cad6c47, +0xf562a43131c43195, 0xb9e8f37474cd7487, 0x09f115f6f6fff6e3, 0x438c4c464605460a, +0x2645a5acac8aac09, 0x970fb589891e893c, 0x4428b414145014a0, 0x42dfbae1e1a3e15b, +0x4e2ca616165816b0, 0xd274f73a3ae83acd, 0xd0d2066969b9696f, 0x2d12410909240948, +0xade0d77070dd70a7, 0x54716fb6b6e2b6d9, 0xb7bd1ed0d067d0ce, 0x7ec7d6eded93ed3b, +0xdb85e2cccc17cc2e, 0x578468424215422a, 0xc22d2c98985a98b4, 0x0e55eda4a4aaa449, +0x8850752828a0285d, 0x31b8865c5c6d5cda, 0x3fed6bf8f8c7f893, 0xa411c28686228644, +] +C4 = [ +0xc07830d818186018, 0x05af462623238c23, 0x7ef991b8c6c63fc6, 0x136fcdfbe8e887e8, +0x4ca113cb87872687, 0xa9626d11b8b8dab8, 0x0805020901010401, 0x426e9e0d4f4f214f, +0xadee6c9b3636d836, 0x590451ffa6a6a2a6, 0xdebdb90cd2d26fd2, 0xfb06f70ef5f5f3f5, +0xef80f2967979f979, 0x5fcede306f6fa16f, 0xfcef3f6d91917e91, 0xaa07a4f852525552, +0x27fdc04760609d60, 0x89766535bcbccabc, 0xaccd2b379b9b569b, 0x048c018a8e8e028e, +0x71155bd2a3a3b6a3, 0x603c186c0c0c300c, 0xff8af6847b7bf17b, 0xb5e16a803535d435, +0xe8693af51d1d741d, 0x5347ddb3e0e0a7e0, 0xf6acb321d7d77bd7, 0x5eed999cc2c22fc2, +0x6d965c432e2eb82e, 0x627a96294b4b314b, 0xa321e15dfefedffe, 0x8216aed557574157, +0xa8412abd15155415, 0x9fb6eee87777c177, 0xa5eb6e923737dc37, 0x7b56d79ee5e5b3e5, +0x8cd923139f9f469f, 0xd317fd23f0f0e7f0, 0x6a7f94204a4a354a, 0x9e95a944dada4fda, +0xfa25b0a258587d58, 0x06ca8fcfc9c903c9, 0x558d527c2929a429, 0x5022145a0a0a280a, +0xe14f7f50b1b1feb1, 0x691a5dc9a0a0baa0, 0x7fdad6146b6bb16b, 0x5cab17d985852e85, +0x8173673cbdbdcebd, 0xd234ba8f5d5d695d, 0x8050209010104010, 0xf303f507f4f4f7f4, +0x16c08bddcbcb0bcb, 0xedc67cd33e3ef83e, 0x28110a2d05051405, 0x1fe6ce7867678167, +0x7353d597e4e4b7e4, 0x25bb4e0227279c27, 0x3258827341411941, 0x2c9d0ba78b8b168b, +0x510153f6a7a7a6a7, 0xcf94fab27d7de97d, 0xdcfb374995956e95, 0x8e9fad56d8d847d8, +0x8b30eb70fbfbcbfb, 0x2371c1cdeeee9fee, 0xc791f8bb7c7ced7c, 0x17e3cc7166668566, +0xa68ea77bdddd53dd, 0xb84b2eaf17175c17, 0x02468e4547470147, 0x84dc211a9e9e429e, +0x1ec589d4caca0fca, 0x75995a582d2db42d, 0x9179632ebfbfc6bf, 0x381b0e3f07071c07, +0x012347acadad8ead, 0xea2fb4b05a5a755a, 0x6cb51bef83833683, 0x85ff66b63333cc33, +0x3ff2c65c63639163, 0x100a041202020802, 0x39384993aaaa92aa, 0xafa8e2de7171d971, +0x0ecf8dc6c8c807c8, 0xc87d32d119196419, 0x7270923b49493949, 0x869aaf5fd9d943d9, +0xc31df931f2f2eff2, 0x4b48dba8e3e3abe3, 0xe22ab6b95b5b715b, 0x34920dbc88881a88, +0xa4c8293e9a9a529a, 0x2dbe4c0b26269826, 0x8dfa64bf3232c832, 0xe94a7d59b0b0fab0, +0x1b6acff2e9e983e9, 0x78331e770f0f3c0f, 0xe6a6b733d5d573d5, 0x74ba1df480803a80, +0x997c6127bebec2be, 0x26de87ebcdcd13cd, 0xbde468893434d034, 0x7a75903248483d48, +0xab24e354ffffdbff, 0xf78ff48d7a7af57a, 0xf4ea3d6490907a90, 0xc23ebe9d5f5f615f, +0x1da0403d20208020, 0x67d5d00f6868bd68, 0xd07234ca1a1a681a, 0x192c41b7aeae82ae, +0xc95e757db4b4eab4, 0x9a19a8ce54544d54, 0xece53b7f93937693, 0x0daa442f22228822, +0x07e9c86364648d64, 0xdb12ff2af1f1e3f1, 0xbfa2e6cc7373d173, 0x905a248212124812, +0x3a5d807a40401d40, 0x4028104808082008, 0x56e89b95c3c32bc3, 0x337bc5dfecec97ec, +0x9690ab4ddbdb4bdb, 0x611f5fc0a1a1bea1, 0x1c8307918d8d0e8d, 0xf5c97ac83d3df43d, +0xccf1335b97976697, 0x0000000000000000, 0x36d483f9cfcf1bcf, 0x4587566e2b2bac2b, +0x97b3ece17676c576, 0x64b019e682823282, 0xfea9b128d6d67fd6, 0xd87736c31b1b6c1b, +0xc15b7774b5b5eeb5, 0x112943beafaf86af, 0x77dfd41d6a6ab56a, 0xba0da0ea50505d50, +0x124c8a5745450945, 0xcb18fb38f3f3ebf3, 0x9df060ad3030c030, 0x2b74c3c4efef9bef, +0xe5c37eda3f3ffc3f, 0x921caac755554955, 0x791059dba2a2b2a2, 0x0365c9e9eaea8fea, +0x0fecca6a65658965, 0xb9686903babad2ba, 0x65935e4a2f2fbc2f, 0x4ee79d8ec0c027c0, +0xbe81a160dede5fde, 0xe06c38fc1c1c701c, 0xbb2ee746fdfdd3fd, 0x52649a1f4d4d294d, +0xe4e0397692927292, 0x8fbceafa7575c975, 0x301e0c3606061806, 0x249809ae8a8a128a, +0xf940794bb2b2f2b2, 0x6359d185e6e6bfe6, 0x70361c7e0e0e380e, 0xf8633ee71f1f7c1f, +0x37f7c45562629562, 0xeea3b53ad4d477d4, 0x29324d81a8a89aa8, 0xc4f4315296966296, +0x9b3aef62f9f9c3f9, 0x66f697a3c5c533c5, 0x35b14a1025259425, 0xf220b2ab59597959, +0x54ae15d084842a84, 0xb7a7e4c57272d572, 0xd5dd72ec3939e439, 0x5a6198164c4c2d4c, +0xca3bbc945e5e655e, 0xe785f09f7878fd78, 0xddd870e53838e038, 0x148605988c8c0a8c, +0xc6b2bf17d1d163d1, 0x410b57e4a5a5aea5, 0x434dd9a1e2e2afe2, 0x2ff8c24e61619961, +0xf1457b42b3b3f6b3, 0x15a5423421218421, 0x94d625089c9c4a9c, 0xf0663cee1e1e781e, +0x2252866143431143, 0x76fc93b1c7c73bc7, 0xb32be54ffcfcd7fc, 0x2014082404041004, +0xb208a2e351515951, 0xbcc72f2599995e99, 0x4fc4da226d6da96d, 0x68391a650d0d340d, +0x8335e979fafacffa, 0xb684a369dfdf5bdf, 0xd79bfca97e7ee57e, 0x3db4481924249024, +0xc5d776fe3b3bec3b, 0x313d4b9aabab96ab, 0x3ed181f0cece1fce, 0x8855229911114411, +0x0c8903838f8f068f, 0x4a6b9c044e4e254e, 0xd1517366b7b7e6b7, 0x0b60cbe0ebeb8beb, +0xfdcc78c13c3cf03c, 0x7cbf1ffd81813e81, 0xd4fe354094946a94, 0xeb0cf31cf7f7fbf7, +0xa1676f18b9b9deb9, 0x985f268b13134c13, 0x7d9c58512c2cb02c, 0xd6b8bb05d3d36bd3, +0x6b5cd38ce7e7bbe7, 0x57cbdc396e6ea56e, 0x6ef395aac4c437c4, 0x180f061b03030c03, +0x8a13acdc56564556, 0x1a49885e44440d44, 0xdf9efea07f7fe17f, 0x21374f88a9a99ea9, +0x4d8254672a2aa82a, 0xb16d6b0abbbbd6bb, 0x46e29f87c1c123c1, 0xa202a6f153535153, +0xae8ba572dcdc57dc, 0x582716530b0b2c0b, 0x9cd327019d9d4e9d, 0x47c1d82b6c6cad6c, +0x95f562a43131c431, 0x87b9e8f37474cd74, 0xe309f115f6f6fff6, 0x0a438c4c46460546, +0x092645a5acac8aac, 0x3c970fb589891e89, 0xa04428b414145014, 0x5b42dfbae1e1a3e1, +0xb04e2ca616165816, 0xcdd274f73a3ae83a, 0x6fd0d2066969b969, 0x482d124109092409, +0xa7ade0d77070dd70, 0xd954716fb6b6e2b6, 0xceb7bd1ed0d067d0, 0x3b7ec7d6eded93ed, +0x2edb85e2cccc17cc, 0x2a57846842421542, 0xb4c22d2c98985a98, 0x490e55eda4a4aaa4, +0x5d8850752828a028, 0xda31b8865c5c6d5c, 0x933fed6bf8f8c7f8, 0x44a411c286862286, +] +C5 = [ +0x18c07830d8181860, 0x2305af462623238c, 0xc67ef991b8c6c63f, 0xe8136fcdfbe8e887, +0x874ca113cb878726, 0xb8a9626d11b8b8da, 0x0108050209010104, 0x4f426e9e0d4f4f21, +0x36adee6c9b3636d8, 0xa6590451ffa6a6a2, 0xd2debdb90cd2d26f, 0xf5fb06f70ef5f5f3, +0x79ef80f2967979f9, 0x6f5fcede306f6fa1, 0x91fcef3f6d91917e, 0x52aa07a4f8525255, +0x6027fdc04760609d, 0xbc89766535bcbcca, 0x9baccd2b379b9b56, 0x8e048c018a8e8e02, +0xa371155bd2a3a3b6, 0x0c603c186c0c0c30, 0x7bff8af6847b7bf1, 0x35b5e16a803535d4, +0x1de8693af51d1d74, 0xe05347ddb3e0e0a7, 0xd7f6acb321d7d77b, 0xc25eed999cc2c22f, +0x2e6d965c432e2eb8, 0x4b627a96294b4b31, 0xfea321e15dfefedf, 0x578216aed5575741, +0x15a8412abd151554, 0x779fb6eee87777c1, 0x37a5eb6e923737dc, 0xe57b56d79ee5e5b3, +0x9f8cd923139f9f46, 0xf0d317fd23f0f0e7, 0x4a6a7f94204a4a35, 0xda9e95a944dada4f, +0x58fa25b0a258587d, 0xc906ca8fcfc9c903, 0x29558d527c2929a4, 0x0a5022145a0a0a28, +0xb1e14f7f50b1b1fe, 0xa0691a5dc9a0a0ba, 0x6b7fdad6146b6bb1, 0x855cab17d985852e, +0xbd8173673cbdbdce, 0x5dd234ba8f5d5d69, 0x1080502090101040, 0xf4f303f507f4f4f7, +0xcb16c08bddcbcb0b, 0x3eedc67cd33e3ef8, 0x0528110a2d050514, 0x671fe6ce78676781, +0xe47353d597e4e4b7, 0x2725bb4e0227279c, 0x4132588273414119, 0x8b2c9d0ba78b8b16, +0xa7510153f6a7a7a6, 0x7dcf94fab27d7de9, 0x95dcfb374995956e, 0xd88e9fad56d8d847, +0xfb8b30eb70fbfbcb, 0xee2371c1cdeeee9f, 0x7cc791f8bb7c7ced, 0x6617e3cc71666685, +0xdda68ea77bdddd53, 0x17b84b2eaf17175c, 0x4702468e45474701, 0x9e84dc211a9e9e42, +0xca1ec589d4caca0f, 0x2d75995a582d2db4, 0xbf9179632ebfbfc6, 0x07381b0e3f07071c, +0xad012347acadad8e, 0x5aea2fb4b05a5a75, 0x836cb51bef838336, 0x3385ff66b63333cc, +0x633ff2c65c636391, 0x02100a0412020208, 0xaa39384993aaaa92, 0x71afa8e2de7171d9, +0xc80ecf8dc6c8c807, 0x19c87d32d1191964, 0x497270923b494939, 0xd9869aaf5fd9d943, +0xf2c31df931f2f2ef, 0xe34b48dba8e3e3ab, 0x5be22ab6b95b5b71, 0x8834920dbc88881a, +0x9aa4c8293e9a9a52, 0x262dbe4c0b262698, 0x328dfa64bf3232c8, 0xb0e94a7d59b0b0fa, +0xe91b6acff2e9e983, 0x0f78331e770f0f3c, 0xd5e6a6b733d5d573, 0x8074ba1df480803a, +0xbe997c6127bebec2, 0xcd26de87ebcdcd13, 0x34bde468893434d0, 0x487a75903248483d, +0xffab24e354ffffdb, 0x7af78ff48d7a7af5, 0x90f4ea3d6490907a, 0x5fc23ebe9d5f5f61, +0x201da0403d202080, 0x6867d5d00f6868bd, 0x1ad07234ca1a1a68, 0xae192c41b7aeae82, +0xb4c95e757db4b4ea, 0x549a19a8ce54544d, 0x93ece53b7f939376, 0x220daa442f222288, +0x6407e9c86364648d, 0xf1db12ff2af1f1e3, 0x73bfa2e6cc7373d1, 0x12905a2482121248, +0x403a5d807a40401d, 0x0840281048080820, 0xc356e89b95c3c32b, 0xec337bc5dfecec97, +0xdb9690ab4ddbdb4b, 0xa1611f5fc0a1a1be, 0x8d1c8307918d8d0e, 0x3df5c97ac83d3df4, +0x97ccf1335b979766, 0x0000000000000000, 0xcf36d483f9cfcf1b, 0x2b4587566e2b2bac, +0x7697b3ece17676c5, 0x8264b019e6828232, 0xd6fea9b128d6d67f, 0x1bd87736c31b1b6c, +0xb5c15b7774b5b5ee, 0xaf112943beafaf86, 0x6a77dfd41d6a6ab5, 0x50ba0da0ea50505d, +0x45124c8a57454509, 0xf3cb18fb38f3f3eb, 0x309df060ad3030c0, 0xef2b74c3c4efef9b, +0x3fe5c37eda3f3ffc, 0x55921caac7555549, 0xa2791059dba2a2b2, 0xea0365c9e9eaea8f, +0x650fecca6a656589, 0xbab9686903babad2, 0x2f65935e4a2f2fbc, 0xc04ee79d8ec0c027, +0xdebe81a160dede5f, 0x1ce06c38fc1c1c70, 0xfdbb2ee746fdfdd3, 0x4d52649a1f4d4d29, +0x92e4e03976929272, 0x758fbceafa7575c9, 0x06301e0c36060618, 0x8a249809ae8a8a12, +0xb2f940794bb2b2f2, 0xe66359d185e6e6bf, 0x0e70361c7e0e0e38, 0x1ff8633ee71f1f7c, +0x6237f7c455626295, 0xd4eea3b53ad4d477, 0xa829324d81a8a89a, 0x96c4f43152969662, +0xf99b3aef62f9f9c3, 0xc566f697a3c5c533, 0x2535b14a10252594, 0x59f220b2ab595979, +0x8454ae15d084842a, 0x72b7a7e4c57272d5, 0x39d5dd72ec3939e4, 0x4c5a6198164c4c2d, +0x5eca3bbc945e5e65, 0x78e785f09f7878fd, 0x38ddd870e53838e0, 0x8c148605988c8c0a, +0xd1c6b2bf17d1d163, 0xa5410b57e4a5a5ae, 0xe2434dd9a1e2e2af, 0x612ff8c24e616199, +0xb3f1457b42b3b3f6, 0x2115a54234212184, 0x9c94d625089c9c4a, 0x1ef0663cee1e1e78, +0x4322528661434311, 0xc776fc93b1c7c73b, 0xfcb32be54ffcfcd7, 0x0420140824040410, +0x51b208a2e3515159, 0x99bcc72f2599995e, 0x6d4fc4da226d6da9, 0x0d68391a650d0d34, +0xfa8335e979fafacf, 0xdfb684a369dfdf5b, 0x7ed79bfca97e7ee5, 0x243db44819242490, +0x3bc5d776fe3b3bec, 0xab313d4b9aabab96, 0xce3ed181f0cece1f, 0x1188552299111144, +0x8f0c8903838f8f06, 0x4e4a6b9c044e4e25, 0xb7d1517366b7b7e6, 0xeb0b60cbe0ebeb8b, +0x3cfdcc78c13c3cf0, 0x817cbf1ffd81813e, 0x94d4fe354094946a, 0xf7eb0cf31cf7f7fb, +0xb9a1676f18b9b9de, 0x13985f268b13134c, 0x2c7d9c58512c2cb0, 0xd3d6b8bb05d3d36b, +0xe76b5cd38ce7e7bb, 0x6e57cbdc396e6ea5, 0xc46ef395aac4c437, 0x03180f061b03030c, +0x568a13acdc565645, 0x441a49885e44440d, 0x7fdf9efea07f7fe1, 0xa921374f88a9a99e, +0x2a4d8254672a2aa8, 0xbbb16d6b0abbbbd6, 0xc146e29f87c1c123, 0x53a202a6f1535351, +0xdcae8ba572dcdc57, 0x0b582716530b0b2c, 0x9d9cd327019d9d4e, 0x6c47c1d82b6c6cad, +0x3195f562a43131c4, 0x7487b9e8f37474cd, 0xf6e309f115f6f6ff, 0x460a438c4c464605, +0xac092645a5acac8a, 0x893c970fb589891e, 0x14a04428b4141450, 0xe15b42dfbae1e1a3, +0x16b04e2ca6161658, 0x3acdd274f73a3ae8, 0x696fd0d2066969b9, 0x09482d1241090924, +0x70a7ade0d77070dd, 0xb6d954716fb6b6e2, 0xd0ceb7bd1ed0d067, 0xed3b7ec7d6eded93, +0xcc2edb85e2cccc17, 0x422a578468424215, 0x98b4c22d2c98985a, 0xa4490e55eda4a4aa, +0x285d8850752828a0, 0x5cda31b8865c5c6d, 0xf8933fed6bf8f8c7, 0x8644a411c2868622, +] +C6 = [ +0x6018c07830d81818, 0x8c2305af46262323, 0x3fc67ef991b8c6c6, 0x87e8136fcdfbe8e8, +0x26874ca113cb8787, 0xdab8a9626d11b8b8, 0x0401080502090101, 0x214f426e9e0d4f4f, +0xd836adee6c9b3636, 0xa2a6590451ffa6a6, 0x6fd2debdb90cd2d2, 0xf3f5fb06f70ef5f5, +0xf979ef80f2967979, 0xa16f5fcede306f6f, 0x7e91fcef3f6d9191, 0x5552aa07a4f85252, +0x9d6027fdc0476060, 0xcabc89766535bcbc, 0x569baccd2b379b9b, 0x028e048c018a8e8e, +0xb6a371155bd2a3a3, 0x300c603c186c0c0c, 0xf17bff8af6847b7b, 0xd435b5e16a803535, +0x741de8693af51d1d, 0xa7e05347ddb3e0e0, 0x7bd7f6acb321d7d7, 0x2fc25eed999cc2c2, +0xb82e6d965c432e2e, 0x314b627a96294b4b, 0xdffea321e15dfefe, 0x41578216aed55757, +0x5415a8412abd1515, 0xc1779fb6eee87777, 0xdc37a5eb6e923737, 0xb3e57b56d79ee5e5, +0x469f8cd923139f9f, 0xe7f0d317fd23f0f0, 0x354a6a7f94204a4a, 0x4fda9e95a944dada, +0x7d58fa25b0a25858, 0x03c906ca8fcfc9c9, 0xa429558d527c2929, 0x280a5022145a0a0a, +0xfeb1e14f7f50b1b1, 0xbaa0691a5dc9a0a0, 0xb16b7fdad6146b6b, 0x2e855cab17d98585, +0xcebd8173673cbdbd, 0x695dd234ba8f5d5d, 0x4010805020901010, 0xf7f4f303f507f4f4, +0x0bcb16c08bddcbcb, 0xf83eedc67cd33e3e, 0x140528110a2d0505, 0x81671fe6ce786767, +0xb7e47353d597e4e4, 0x9c2725bb4e022727, 0x1941325882734141, 0x168b2c9d0ba78b8b, +0xa6a7510153f6a7a7, 0xe97dcf94fab27d7d, 0x6e95dcfb37499595, 0x47d88e9fad56d8d8, +0xcbfb8b30eb70fbfb, 0x9fee2371c1cdeeee, 0xed7cc791f8bb7c7c, 0x856617e3cc716666, +0x53dda68ea77bdddd, 0x5c17b84b2eaf1717, 0x014702468e454747, 0x429e84dc211a9e9e, +0x0fca1ec589d4caca, 0xb42d75995a582d2d, 0xc6bf9179632ebfbf, 0x1c07381b0e3f0707, +0x8ead012347acadad, 0x755aea2fb4b05a5a, 0x36836cb51bef8383, 0xcc3385ff66b63333, +0x91633ff2c65c6363, 0x0802100a04120202, 0x92aa39384993aaaa, 0xd971afa8e2de7171, +0x07c80ecf8dc6c8c8, 0x6419c87d32d11919, 0x39497270923b4949, 0x43d9869aaf5fd9d9, +0xeff2c31df931f2f2, 0xabe34b48dba8e3e3, 0x715be22ab6b95b5b, 0x1a8834920dbc8888, +0x529aa4c8293e9a9a, 0x98262dbe4c0b2626, 0xc8328dfa64bf3232, 0xfab0e94a7d59b0b0, +0x83e91b6acff2e9e9, 0x3c0f78331e770f0f, 0x73d5e6a6b733d5d5, 0x3a8074ba1df48080, +0xc2be997c6127bebe, 0x13cd26de87ebcdcd, 0xd034bde468893434, 0x3d487a7590324848, +0xdbffab24e354ffff, 0xf57af78ff48d7a7a, 0x7a90f4ea3d649090, 0x615fc23ebe9d5f5f, +0x80201da0403d2020, 0xbd6867d5d00f6868, 0x681ad07234ca1a1a, 0x82ae192c41b7aeae, +0xeab4c95e757db4b4, 0x4d549a19a8ce5454, 0x7693ece53b7f9393, 0x88220daa442f2222, +0x8d6407e9c8636464, 0xe3f1db12ff2af1f1, 0xd173bfa2e6cc7373, 0x4812905a24821212, +0x1d403a5d807a4040, 0x2008402810480808, 0x2bc356e89b95c3c3, 0x97ec337bc5dfecec, +0x4bdb9690ab4ddbdb, 0xbea1611f5fc0a1a1, 0x0e8d1c8307918d8d, 0xf43df5c97ac83d3d, +0x6697ccf1335b9797, 0x0000000000000000, 0x1bcf36d483f9cfcf, 0xac2b4587566e2b2b, +0xc57697b3ece17676, 0x328264b019e68282, 0x7fd6fea9b128d6d6, 0x6c1bd87736c31b1b, +0xeeb5c15b7774b5b5, 0x86af112943beafaf, 0xb56a77dfd41d6a6a, 0x5d50ba0da0ea5050, +0x0945124c8a574545, 0xebf3cb18fb38f3f3, 0xc0309df060ad3030, 0x9bef2b74c3c4efef, +0xfc3fe5c37eda3f3f, 0x4955921caac75555, 0xb2a2791059dba2a2, 0x8fea0365c9e9eaea, +0x89650fecca6a6565, 0xd2bab9686903baba, 0xbc2f65935e4a2f2f, 0x27c04ee79d8ec0c0, +0x5fdebe81a160dede, 0x701ce06c38fc1c1c, 0xd3fdbb2ee746fdfd, 0x294d52649a1f4d4d, +0x7292e4e039769292, 0xc9758fbceafa7575, 0x1806301e0c360606, 0x128a249809ae8a8a, +0xf2b2f940794bb2b2, 0xbfe66359d185e6e6, 0x380e70361c7e0e0e, 0x7c1ff8633ee71f1f, +0x956237f7c4556262, 0x77d4eea3b53ad4d4, 0x9aa829324d81a8a8, 0x6296c4f431529696, +0xc3f99b3aef62f9f9, 0x33c566f697a3c5c5, 0x942535b14a102525, 0x7959f220b2ab5959, +0x2a8454ae15d08484, 0xd572b7a7e4c57272, 0xe439d5dd72ec3939, 0x2d4c5a6198164c4c, +0x655eca3bbc945e5e, 0xfd78e785f09f7878, 0xe038ddd870e53838, 0x0a8c148605988c8c, +0x63d1c6b2bf17d1d1, 0xaea5410b57e4a5a5, 0xafe2434dd9a1e2e2, 0x99612ff8c24e6161, +0xf6b3f1457b42b3b3, 0x842115a542342121, 0x4a9c94d625089c9c, 0x781ef0663cee1e1e, +0x1143225286614343, 0x3bc776fc93b1c7c7, 0xd7fcb32be54ffcfc, 0x1004201408240404, +0x5951b208a2e35151, 0x5e99bcc72f259999, 0xa96d4fc4da226d6d, 0x340d68391a650d0d, +0xcffa8335e979fafa, 0x5bdfb684a369dfdf, 0xe57ed79bfca97e7e, 0x90243db448192424, +0xec3bc5d776fe3b3b, 0x96ab313d4b9aabab, 0x1fce3ed181f0cece, 0x4411885522991111, +0x068f0c8903838f8f, 0x254e4a6b9c044e4e, 0xe6b7d1517366b7b7, 0x8beb0b60cbe0ebeb, +0xf03cfdcc78c13c3c, 0x3e817cbf1ffd8181, 0x6a94d4fe35409494, 0xfbf7eb0cf31cf7f7, +0xdeb9a1676f18b9b9, 0x4c13985f268b1313, 0xb02c7d9c58512c2c, 0x6bd3d6b8bb05d3d3, +0xbbe76b5cd38ce7e7, 0xa56e57cbdc396e6e, 0x37c46ef395aac4c4, 0x0c03180f061b0303, +0x45568a13acdc5656, 0x0d441a49885e4444, 0xe17fdf9efea07f7f, 0x9ea921374f88a9a9, +0xa82a4d8254672a2a, 0xd6bbb16d6b0abbbb, 0x23c146e29f87c1c1, 0x5153a202a6f15353, +0x57dcae8ba572dcdc, 0x2c0b582716530b0b, 0x4e9d9cd327019d9d, 0xad6c47c1d82b6c6c, +0xc43195f562a43131, 0xcd7487b9e8f37474, 0xfff6e309f115f6f6, 0x05460a438c4c4646, +0x8aac092645a5acac, 0x1e893c970fb58989, 0x5014a04428b41414, 0xa3e15b42dfbae1e1, +0x5816b04e2ca61616, 0xe83acdd274f73a3a, 0xb9696fd0d2066969, 0x2409482d12410909, +0xdd70a7ade0d77070, 0xe2b6d954716fb6b6, 0x67d0ceb7bd1ed0d0, 0x93ed3b7ec7d6eded, +0x17cc2edb85e2cccc, 0x15422a5784684242, 0x5a98b4c22d2c9898, 0xaaa4490e55eda4a4, +0xa0285d8850752828, 0x6d5cda31b8865c5c, 0xc7f8933fed6bf8f8, 0x228644a411c28686, +] +C7 = [ +0x186018c07830d818, 0x238c2305af462623, 0xc63fc67ef991b8c6, 0xe887e8136fcdfbe8, +0x8726874ca113cb87, 0xb8dab8a9626d11b8, 0x0104010805020901, 0x4f214f426e9e0d4f, +0x36d836adee6c9b36, 0xa6a2a6590451ffa6, 0xd26fd2debdb90cd2, 0xf5f3f5fb06f70ef5, +0x79f979ef80f29679, 0x6fa16f5fcede306f, 0x917e91fcef3f6d91, 0x525552aa07a4f852, +0x609d6027fdc04760, 0xbccabc89766535bc, 0x9b569baccd2b379b, 0x8e028e048c018a8e, +0xa3b6a371155bd2a3, 0x0c300c603c186c0c, 0x7bf17bff8af6847b, 0x35d435b5e16a8035, +0x1d741de8693af51d, 0xe0a7e05347ddb3e0, 0xd77bd7f6acb321d7, 0xc22fc25eed999cc2, +0x2eb82e6d965c432e, 0x4b314b627a96294b, 0xfedffea321e15dfe, 0x5741578216aed557, +0x155415a8412abd15, 0x77c1779fb6eee877, 0x37dc37a5eb6e9237, 0xe5b3e57b56d79ee5, +0x9f469f8cd923139f, 0xf0e7f0d317fd23f0, 0x4a354a6a7f94204a, 0xda4fda9e95a944da, +0x587d58fa25b0a258, 0xc903c906ca8fcfc9, 0x29a429558d527c29, 0x0a280a5022145a0a, +0xb1feb1e14f7f50b1, 0xa0baa0691a5dc9a0, 0x6bb16b7fdad6146b, 0x852e855cab17d985, +0xbdcebd8173673cbd, 0x5d695dd234ba8f5d, 0x1040108050209010, 0xf4f7f4f303f507f4, +0xcb0bcb16c08bddcb, 0x3ef83eedc67cd33e, 0x05140528110a2d05, 0x6781671fe6ce7867, +0xe4b7e47353d597e4, 0x279c2725bb4e0227, 0x4119413258827341, 0x8b168b2c9d0ba78b, +0xa7a6a7510153f6a7, 0x7de97dcf94fab27d, 0x956e95dcfb374995, 0xd847d88e9fad56d8, +0xfbcbfb8b30eb70fb, 0xee9fee2371c1cdee, 0x7ced7cc791f8bb7c, 0x66856617e3cc7166, +0xdd53dda68ea77bdd, 0x175c17b84b2eaf17, 0x47014702468e4547, 0x9e429e84dc211a9e, +0xca0fca1ec589d4ca, 0x2db42d75995a582d, 0xbfc6bf9179632ebf, 0x071c07381b0e3f07, +0xad8ead012347acad, 0x5a755aea2fb4b05a, 0x8336836cb51bef83, 0x33cc3385ff66b633, +0x6391633ff2c65c63, 0x020802100a041202, 0xaa92aa39384993aa, 0x71d971afa8e2de71, +0xc807c80ecf8dc6c8, 0x196419c87d32d119, 0x4939497270923b49, 0xd943d9869aaf5fd9, +0xf2eff2c31df931f2, 0xe3abe34b48dba8e3, 0x5b715be22ab6b95b, 0x881a8834920dbc88, +0x9a529aa4c8293e9a, 0x2698262dbe4c0b26, 0x32c8328dfa64bf32, 0xb0fab0e94a7d59b0, +0xe983e91b6acff2e9, 0x0f3c0f78331e770f, 0xd573d5e6a6b733d5, 0x803a8074ba1df480, +0xbec2be997c6127be, 0xcd13cd26de87ebcd, 0x34d034bde4688934, 0x483d487a75903248, +0xffdbffab24e354ff, 0x7af57af78ff48d7a, 0x907a90f4ea3d6490, 0x5f615fc23ebe9d5f, +0x2080201da0403d20, 0x68bd6867d5d00f68, 0x1a681ad07234ca1a, 0xae82ae192c41b7ae, +0xb4eab4c95e757db4, 0x544d549a19a8ce54, 0x937693ece53b7f93, 0x2288220daa442f22, +0x648d6407e9c86364, 0xf1e3f1db12ff2af1, 0x73d173bfa2e6cc73, 0x124812905a248212, +0x401d403a5d807a40, 0x0820084028104808, 0xc32bc356e89b95c3, 0xec97ec337bc5dfec, +0xdb4bdb9690ab4ddb, 0xa1bea1611f5fc0a1, 0x8d0e8d1c8307918d, 0x3df43df5c97ac83d, +0x976697ccf1335b97, 0x0000000000000000, 0xcf1bcf36d483f9cf, 0x2bac2b4587566e2b, +0x76c57697b3ece176, 0x82328264b019e682, 0xd67fd6fea9b128d6, 0x1b6c1bd87736c31b, +0xb5eeb5c15b7774b5, 0xaf86af112943beaf, 0x6ab56a77dfd41d6a, 0x505d50ba0da0ea50, +0x450945124c8a5745, 0xf3ebf3cb18fb38f3, 0x30c0309df060ad30, 0xef9bef2b74c3c4ef, +0x3ffc3fe5c37eda3f, 0x554955921caac755, 0xa2b2a2791059dba2, 0xea8fea0365c9e9ea, +0x6589650fecca6a65, 0xbad2bab9686903ba, 0x2fbc2f65935e4a2f, 0xc027c04ee79d8ec0, +0xde5fdebe81a160de, 0x1c701ce06c38fc1c, 0xfdd3fdbb2ee746fd, 0x4d294d52649a1f4d, +0x927292e4e0397692, 0x75c9758fbceafa75, 0x061806301e0c3606, 0x8a128a249809ae8a, +0xb2f2b2f940794bb2, 0xe6bfe66359d185e6, 0x0e380e70361c7e0e, 0x1f7c1ff8633ee71f, +0x62956237f7c45562, 0xd477d4eea3b53ad4, 0xa89aa829324d81a8, 0x966296c4f4315296, +0xf9c3f99b3aef62f9, 0xc533c566f697a3c5, 0x25942535b14a1025, 0x597959f220b2ab59, +0x842a8454ae15d084, 0x72d572b7a7e4c572, 0x39e439d5dd72ec39, 0x4c2d4c5a6198164c, +0x5e655eca3bbc945e, 0x78fd78e785f09f78, 0x38e038ddd870e538, 0x8c0a8c148605988c, +0xd163d1c6b2bf17d1, 0xa5aea5410b57e4a5, 0xe2afe2434dd9a1e2, 0x6199612ff8c24e61, +0xb3f6b3f1457b42b3, 0x21842115a5423421, 0x9c4a9c94d625089c, 0x1e781ef0663cee1e, +0x4311432252866143, 0xc73bc776fc93b1c7, 0xfcd7fcb32be54ffc, 0x0410042014082404, +0x515951b208a2e351, 0x995e99bcc72f2599, 0x6da96d4fc4da226d, 0x0d340d68391a650d, +0xfacffa8335e979fa, 0xdf5bdfb684a369df, 0x7ee57ed79bfca97e, 0x2490243db4481924, +0x3bec3bc5d776fe3b, 0xab96ab313d4b9aab, 0xce1fce3ed181f0ce, 0x1144118855229911, +0x8f068f0c8903838f, 0x4e254e4a6b9c044e, 0xb7e6b7d1517366b7, 0xeb8beb0b60cbe0eb, +0x3cf03cfdcc78c13c, 0x813e817cbf1ffd81, 0x946a94d4fe354094, 0xf7fbf7eb0cf31cf7, +0xb9deb9a1676f18b9, 0x134c13985f268b13, 0x2cb02c7d9c58512c, 0xd36bd3d6b8bb05d3, +0xe7bbe76b5cd38ce7, 0x6ea56e57cbdc396e, 0xc437c46ef395aac4, 0x030c03180f061b03, +0x5645568a13acdc56, 0x440d441a49885e44, 0x7fe17fdf9efea07f, 0xa99ea921374f88a9, +0x2aa82a4d8254672a, 0xbbd6bbb16d6b0abb, 0xc123c146e29f87c1, 0x535153a202a6f153, +0xdc57dcae8ba572dc, 0x0b2c0b582716530b, 0x9d4e9d9cd327019d, 0x6cad6c47c1d82b6c, +0x31c43195f562a431, 0x74cd7487b9e8f374, 0xf6fff6e309f115f6, 0x4605460a438c4c46, +0xac8aac092645a5ac, 0x891e893c970fb589, 0x145014a04428b414, 0xe1a3e15b42dfbae1, +0x165816b04e2ca616, 0x3ae83acdd274f73a, 0x69b9696fd0d20669, 0x092409482d124109, +0x70dd70a7ade0d770, 0xb6e2b6d954716fb6, 0xd067d0ceb7bd1ed0, 0xed93ed3b7ec7d6ed, +0xcc17cc2edb85e2cc, 0x4215422a57846842, 0x985a98b4c22d2c98, 0xa4aaa4490e55eda4, +0x28a0285d88507528, 0x5c6d5cda31b8865c, 0xf8c7f8933fed6bf8, 0x86228644a411c286, +] + +rc = [ +0x0000000000000000, +0x1823c6e887b8014f, +0x36a6d2f5796f9152, +0x60bc9b8ea30c7b35, +0x1de0d7c22e4bfe57, +0x157737e59ff04ada, +0x58c9290ab1a06b85, +0xbd5d10f4cb3e0567, +0xe427418ba77d95d8, +0xfbee7c66dd17479e, +0xca2dbf07ad5a8333 +] + +DIGESTBYTES = 64 +class WhirlpoolStruct: + def __init__(self): + self.bitLength = [0]*32 + self.buffer = [0]*64 + self.bufferBits = 0 + self.bufferPos = 0 + self.hash = [0]*8 + +def WhirlpoolInit(ctx): + ctx = WhirlpoolStruct() + return + +def WhirlpoolAdd(source, sourceBits, ctx): + source = [ord(s)&0xff for s in source] + + carry = 0 + value = sourceBits + i = 31 + while i >= 0 and value != 0: + carry += ctx.bitLength[i] + ((value % 0x100000000) & 0xff) + ctx.bitLength[i] = carry % 0x100 + carry >>= 8 + value >>= 8 + i -= 1 + + bufferBits = ctx.bufferBits + bufferPos = ctx.bufferPos + sourcePos = 0 + sourceGap = (8 - (sourceBits & 7)) & 7 + bufferRem = ctx.bufferBits & 7 + buffr = ctx.buffer + + while sourceBits > 8: + b = ((source[sourcePos] << sourceGap) & 0xff) | ((source[sourcePos + 1] & 0xff) >> (8 - sourceGap)) + buffr[bufferPos] |= (b >> bufferRem) % 0x100 + bufferPos += 1 + bufferBits += 8 - bufferRem + if bufferBits == 512: + processBuffer(ctx) + bufferBits = 0 + bufferPos = 0 + + buffr[bufferPos] = b << (8 - bufferRem) + bufferBits += bufferRem + + sourceBits -= 8 + sourcePos += 1 + + b = (source[sourcePos] << sourceGap) & 0xff + buffr[bufferPos] |= b >> bufferRem + if bufferRem + sourceBits < 8: + bufferBits += sourceBits + else: + bufferPos += 1 + bufferBits += 8 - bufferRem + sourceBits -= 8 - bufferRem + if bufferBits == 512: + processBuffer(ctx) + bufferBits = 0 + bufferPos = 0 + buffr[bufferPos] = b << (8 - bufferRem) + bufferBits += sourceBits + ctx.bufferBits = bufferBits + ctx.bufferPos = bufferPos + +def WhirlpoolFinalize(ctx): + bufferPos = ctx.bufferPos + ctx.buffer[bufferPos] |= 0x80 >> (ctx.bufferBits & 7) + bufferPos += 1 + if bufferPos > 32: + if bufferPos < 64: + for i in xrange(64 - bufferPos): + ctx.buffer[bufferPos+i] = 0 + processBuffer(ctx) + bufferPos = 0 + if bufferPos < 32: + for i in xrange(32 - bufferPos): + ctx.buffer[bufferPos+i] = 0 + bufferPos = 32 + for i in xrange(32): + ctx.buffer[32+i] = ctx.bitLength[i] + processBuffer(ctx) + digest = '' + for i in xrange(8): + digest += chr((ctx.hash[i] >> 56) % 0x100) + digest += chr((ctx.hash[i] >> 48) % 0x100) + digest += chr((ctx.hash[i] >> 40) % 0x100) + digest += chr((ctx.hash[i] >> 32) % 0x100) + digest += chr((ctx.hash[i] >> 24) % 0x100) + digest += chr((ctx.hash[i] >> 16) % 0x100) + digest += chr((ctx.hash[i] >> 8) % 0x100) + digest += chr((ctx.hash[i]) % 0x100) + ctx.bufferPos = bufferPos + return digest + +def CDo(buf, a0, a1, a2, a3, a4, a5, a6, a7): + return C0[((buf[a0] >> 56) % 0x100000000) & 0xff] ^ \ + C1[((buf[a1] >> 48) % 0x100000000) & 0xff] ^ \ + C2[((buf[a2] >> 40) % 0x100000000) & 0xff] ^ \ + C3[((buf[a3] >> 32) % 0x100000000) & 0xff] ^ \ + C4[((buf[a4] >> 24) % 0x100000000) & 0xff] ^ \ + C5[((buf[a5] >> 16) % 0x100000000) & 0xff] ^ \ + C6[((buf[a6] >> 8) % 0x100000000) & 0xff] ^ \ + C7[((buf[a7] >> 0) % 0x100000000) & 0xff] + +def processBuffer(ctx): + i, r = 0, 0 + K = [0]*8 + block = [0]*8 + state = [0]*8 + L = [0]*8 + buffr = ctx.buffer + + buf_cnt = 0 + for i in xrange(8): + block[i] = ((buffr[buf_cnt+0] & 0xff) << 56) ^ \ + ((buffr[buf_cnt+1] & 0xff) << 48) ^ \ + ((buffr[buf_cnt+2] & 0xff) << 40) ^ \ + ((buffr[buf_cnt+3] & 0xff) << 32) ^ \ + ((buffr[buf_cnt+4] & 0xff) << 24) ^ \ + ((buffr[buf_cnt+5] & 0xff) << 16) ^ \ + ((buffr[buf_cnt+6] & 0xff) << 8) ^ \ + ((buffr[buf_cnt+7] & 0xff) << 0) + buf_cnt += 8 + for i in xrange(8): + K[i] = ctx.hash[i] + state[i] = block[i] ^ K[i] + + for r in xrange(1, R+1): + L[0] = CDo(K, 0, 7, 6, 5, 4, 3, 2, 1) ^ rc[r] + L[1] = CDo(K, 1, 0, 7, 6, 5, 4, 3, 2) + L[2] = CDo(K, 2, 1, 0, 7, 6, 5, 4, 3) + L[3] = CDo(K, 3, 2, 1, 0, 7, 6, 5, 4) + L[4] = CDo(K, 4, 3, 2, 1, 0, 7, 6, 5) + L[5] = CDo(K, 5, 4, 3, 2, 1, 0, 7, 6) + L[6] = CDo(K, 6, 5, 4, 3, 2, 1, 0, 7) + L[7] = CDo(K, 7, 6, 5, 4, 3, 2, 1, 0) + for i in xrange(8): + K[i] = L[i] + L[0] = CDo(state, 0, 7, 6, 5, 4, 3, 2, 1) ^ K[0] + L[1] = CDo(state, 1, 0, 7, 6, 5, 4, 3, 2) ^ K[1] + L[2] = CDo(state, 2, 1, 0, 7, 6, 5, 4, 3) ^ K[2] + L[3] = CDo(state, 3, 2, 1, 0, 7, 6, 5, 4) ^ K[3] + L[4] = CDo(state, 4, 3, 2, 1, 0, 7, 6, 5) ^ K[4] + L[5] = CDo(state, 5, 4, 3, 2, 1, 0, 7, 6) ^ K[5] + L[6] = CDo(state, 6, 5, 4, 3, 2, 1, 0, 7) ^ K[6] + L[7] = CDo(state, 7, 6, 5, 4, 3, 2, 1, 0) ^ K[7] + for i in xrange(8): + state[i] = L[i] + # apply the Miyaguchi-Preneel compression function + for i in xrange(8): + ctx.hash[i] ^= state[i] ^ block[i] + return + +# +# Tests. +# + +assert Whirlpool('The quick brown fox jumps over the lazy dog').hexdigest() == \ + 'b97de512e91e3828b40d2b0fdce9ceb3c4a71f9bea8d88e75c4fa854df36725fd2b52eb6544edcacd6f8beddfea403cb55ae31f03ad62a5ef54e42ee82c3fb35' +assert Whirlpool('The quick brown fox jumps over the lazy eog').hexdigest() == \ + 'c27ba124205f72e6847f3e19834f925cc666d0974167af915bb462420ed40cc50900d85a1f923219d832357750492d5c143011a76988344c2635e69d06f2d38c' +assert Whirlpool('').hexdigest() == \ + '19fa61d75522a4669b44e39c1d2e1726c530232130d407f89afee0964997f7a73e83be698b288febcf88e3e03c4f0757ea8964e59b63d93708b138cc42a66eb3' [-- Attachment #1.3: portage-r15309-change-manifest2-hash-defaults.patch --] [-- Type: text/plain, Size: 776 bytes --] diff -Nuarp trunk.orig/pym/portage/const.py trunk/pym/portage/const.py --- trunk.orig/pym/portage/const.py 2010-02-01 04:59:27.000000000 +0000 +++ trunk/pym/portage/const.py 2010-02-01 04:14:00.000000000 +0000 @@ -86,10 +86,10 @@ EAPI = 3 HASHING_BLOCKSIZE = 32768 MANIFEST1_HASH_FUNCTIONS = ("MD5", "SHA256", "RMD160") -MANIFEST2_HASH_FUNCTIONS = ("SHA1", "SHA256", "RMD160") +MANIFEST2_HASH_FUNCTIONS = ("SHA256", "SHA512", "WHIRLPOOL") MANIFEST1_REQUIRED_HASH = "MD5" -MANIFEST2_REQUIRED_HASH = "SHA1" +MANIFEST2_REQUIRED_HASH = "SHA256" # Change to WHIRLPOOL after 2010/09/01 MANIFEST2_IDENTIFIERS = ("AUX", "MISC", "DIST", "EBUILD") # =========================================================================== [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP59 - Manifest2 hashes 2010-01-31 9:57 ` [gentoo-dev] GLEP59 - Manifest2 hashes Robin H. Johnson 2010-02-01 5:05 ` Robin H. Johnson @ 2010-02-01 8:23 ` Doug Goldstein 2010-02-02 6:06 ` Denis Dupeyron 2010-02-02 6:09 ` Robin H. Johnson 1 sibling, 2 replies; 16+ messages in thread From: Doug Goldstein @ 2010-02-01 8:23 UTC (permalink / raw To: gentoo-dev On Sun, Jan 31, 2010 at 3:57 AM, Robin H. Johnson <robbat2@gentoo.org> wrote: <snip> > > The SHA512 algorithm is available in Python 2.5, which has been a > dependency of Portage since approximately Python 2.1.6.13. <snip> I hate to nitpick, but I believe you meant Portage in that line. However, great work on this GLEP, you've put forth some good solid research into it. I do hope that we don't intend on settling on SHA512 as the end all solution as well. We should retain a method for bumping the hashing algorithm used when the SHA-3 family becomes available. -- Doug Goldstein ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP59 - Manifest2 hashes 2010-02-01 8:23 ` Doug Goldstein @ 2010-02-02 6:06 ` Denis Dupeyron 2010-02-04 2:57 ` Robin H. Johnson 2010-02-02 6:09 ` Robin H. Johnson 1 sibling, 1 reply; 16+ messages in thread From: Denis Dupeyron @ 2010-02-02 6:06 UTC (permalink / raw To: gentoo-dev On Mon, Feb 1, 2010 at 1:23 AM, Doug Goldstein <cardoe@gentoo.org> wrote: > However, great work on this GLEP, you've put forth some good solid > research into it. Agreed. I would suggest to use this series of GLEPs as examples of what to do for future GLEP writers. > I do hope that we don't intend on settling on SHA512 as the end all > solution as well. We should retain a method for bumping the hashing > algorithm used when the SHA-3 family becomes available. From the way I understand it the GLEP implies that we can add hashes at will. But that's a good point, and a one-liner somewhere making it explicit would be useful. Thus, in "What should be done" I would I would for example replace "We should be prepared to add stronger checksums wherever possible, and to remove those that have been defeated." with: "Stronger checksums shall be added as soon as an implementation is available in Portage. Weak checksums may be removed as long as the depreciation process is followed (see below)." And then, in "Checksum depreciation timing" I would prefer that the description of what needs to be done in the present situation was used as an example after a more general rule is stated. Something like: "At least one older algorithm must remain until the new one(s) has (have) been in stable Portage for minimum one year." The one year period is debatable, what matters is we have well defined rules in order to avoid future flamewars. Denis. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP59 - Manifest2 hashes 2010-02-02 6:06 ` Denis Dupeyron @ 2010-02-04 2:57 ` Robin H. Johnson 0 siblings, 0 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-02-04 2:57 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2248 bytes --] On Mon, Feb 01, 2010 at 11:06:15PM -0700, Denis Dupeyron wrote: > Agreed. I would suggest to use this series of GLEPs as examples of > what to do for future GLEP writers. I've actual considered breaking them up even further. > replace > "We should be prepared to add stronger checksums wherever possible, > and to remove those that have been defeated." > with: > "Stronger checksums shall be added as soon as an implementation is > available in Portage. Weak checksums may be removed as long as the > depreciation process is followed (see below)." +1 on that wording, I'll commit when I am next able to. Do see already how I partially adapted for Cardoe's requests. > And then, in "Checksum depreciation timing" I would prefer that the > description of what needs to be done in the present situation was used > as an example after a more general rule is stated. Something like: I'd propose the following variant: ===== A minimum set of depreciated checksums shall be maintained only to support old package manager versions where needed by historically used trees: - New package manager versions should NOT use depreciated checksums in Manifests when newer checksums are available. - New trees with that have never used the depreciated checksums may omit them for reasons of size, but are still strongly suggested to include them. - Removal of depreciated checksums shall happen after no less than 18 months or one major Portage version cycle, whichever is greater. ===== I'm not editing these into the checksum GLEP right now, as I'm sitting in the food court at the airport, with my flight boarding shortly. Most probably will be committed from my hotel room tomorrow night in Brussels. Signing off now, from an airport with bizarre wireless: More than 45% of connections fail to start, but when they do, they're good for more than 20Mbit. That's after you deal with the their broken DNS in the auth mechanism (I'm probably the only person with working wireless right now, so it's all the bandwidth to myself). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP59 - Manifest2 hashes 2010-02-01 8:23 ` Doug Goldstein 2010-02-02 6:06 ` Denis Dupeyron @ 2010-02-02 6:09 ` Robin H. Johnson 1 sibling, 0 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-02-02 6:09 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1092 bytes --] On Mon, Feb 01, 2010 at 02:23:42AM -0600, Doug Goldstein wrote: > On Sun, Jan 31, 2010 at 3:57 AM, Robin H. Johnson <robbat2@gentoo.org> wrote: > <snip> > > > > The SHA512 algorithm is available in Python 2.5, which has been a > > dependency of Portage since approximately Python 2.1.6.13. > <snip> > I hate to nitpick, but I believe you meant Portage in that line. Thanks :-) Fixed. > However, great work on this GLEP, you've put forth some good solid > research into it. > > I do hope that we don't intend on settling on SHA512 as the end all > solution as well. We should retain a method for bumping the hashing > algorithm used when the SHA-3 family becomes available. The present Portage logic I believe requires SHA1 still be present (so I'm not sure how good the second patch I gave would be), and I'd like that to change to rather be the strongest supported & available algorithm. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] GLEP60 - Manifest2 filetypes 2010-01-31 9:20 [gentoo-dev] Tree-signing GLEPs update Robin H. Johnson 2010-01-31 9:48 ` [gentoo-dev] GLEP58 - MetaManifest Robin H. Johnson 2010-01-31 9:57 ` [gentoo-dev] GLEP59 - Manifest2 hashes Robin H. Johnson @ 2010-01-31 10:01 ` Robin H. Johnson 2010-01-31 10:04 ` [gentoo-dev] GLEP61 - Manifest2 compression Robin H. Johnson 2010-01-31 10:11 ` [gentoo-dev] Tree-signing GLEPS review notes Robin H. Johnson 4 siblings, 0 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-01-31 10:01 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 549 bytes --] Changes: - This GLEP is able to stand independently of GLEP58. - 'UNKNOWN' type is now called 'OTHER', per ulm's suggestion. - Patches should be considered as type 'EXEC' - Type 'EXEC' may be used outside the files/ directory. (eg scripts, parts of profiles) - Logic for dealing with future unknown types. - Patterns are examples only, not exhaustive lists. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #1.2: glep-0060.txt --] [-- Type: text/plain, Size: 8723 bytes --] GLEP: 60 Title: Manifest2 filetypes Version: $Revision: 1.9 $ Last-Modified: $Date: 2010/01/31 09:55:43 $ Author: Robin Hugh Johnson <robbat2@gentoo.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 44 Created: November 2007 Updated: June 2008, July 2008, October 2008, January 2010 Updates: 44 Post-History: December 2009, January 2010 Abstract ======== Clarification of the Manifest2 [#GLEP44] specification, including new types to help in the tree-signing specification. Motivation ========== [#GLEP44] was not entirely clear on the usage of filetype specifiers. This document serves to provide some of the internal logic used by Portage at the point of writing, as well as adding new types to cover the rest of the tree, for the purposes of tree-signing coverage. This GLEP is not mandatory for the tree-signing specification, but instead aims to clarify the usage of the Manifest2 filetype specifiers, and note which types signify files that are allowed to be missing from the tree (e.g. a user excluding a package or category). As such, it is also able to stand on it's own. Specification ============= General ------- For any given directory with a Manifest file, every file located in that directory, or a sub-directory must be listed in that Manifest file, unless stated otherwise in the following sections. The Manifest file must not contain an entry for itself. Excluded files -------------- When generating or validating a Manifest, or committing to a version control system, the package manager should endeavour to ignore files created by a version control system, backup files from text editors. A non-exhaustive list is suggested here: ``CVS/``, ``.svn/``, ``.bzr/``, ``.git/``, ``.hg/``, ``.#*``, ``*.rej``, ``*.orig``, ``*.bak``, ``*~``. Additionally, for a transitional Manifest1->Manifest2 system, old-style digest files located in a 'files/' directory, may be excluded from Manifest2 generation, or included with a type of MISC. Under strict security conditions, the exclusion list may be ignored during validation if the existence of a file would be considered a security risk. Existing filetypes: ------------------- AUX ~~~ - The AUX type is used for all items under the 'files' subdirectory. - They should be verified relative to $FILESDIR. - The string 'files/' is left out of the Manifest line. - The absence of a file mentioned by AUX must be treated as an error. - The AUX type is intended to denote potentially executable content (either directly or indirectly), that must be treated an error if modified or absent. EBUILD ~~~~~~ - The EBUILD type is used solely for files ending in .ebuild, or other suffixes as defined by the EAPI. - The files are located in the same directory as the Manifest file. - The modification or absence of a file mentioned by EBUILD must be treated as an error. DIST ~~~~ - The DIST type is used for distfiles - They may be found directly via the $DISTDIR setting of the package manager. - During simple verification of a Manifest, a missing DIST file should not be consider as a validation error (it is however a failure to fetch or unpack). MISC ~~~~ - The MISC type covers all remaining files in a directory. - MISC is intended to mark all content that was not used in some way that directly affected execution of the package manager. - This includes metadata.xml and ChangeLog entries, and any other purely informational content. - MISC entries where the file is missing may optionally be ignored as by non-strict package managers. - It should be possible to install a package while all MISC entries have been deleted from the tree. New filetypes: -------------- _INFO (new, abstract) ~~~~~~~~~~~~~~~~~~~~~ - This is the functionality of the old AUX, but does not include the implicit 'files/' prefix in the path, and is verified relative to the working directory instead of $FILESDIR. - The modification or absence of a file listed as a _INFO-derived type is not an error unless the package manager is attempting to be strict. _CRIT (new, abstract) ~~~~~~~~~~~~~~~~~~~~~ - _CRIT is based off the _INFO type. - The modification or absence of a file listed as a _CRIT-derived type MUST be treated as an error. EBUILD ~~~~~~ - Now derived from _CRIT. - Otherwise unchanged. DIST ~~~~ - Now derived from _CRIT. - Otherwise unchanged. MISC ~~~~ - Now derived from _INFO. - Otherwise unchanged. MANIFEST (new) ~~~~~~~~~~~~~~ - The MANIFEST type is explicitly to cover all nested Manifest files. - During validation, this serves as an indicator that the package manager may need to check subtree Manifest file. - A missing MANIFEST file may be treated as a minor (e.g. excluding an entire category) or critical validation failure. - The failure should be considered as critical only if files that would be directly covered by this Manifest are missing. Deletion of a category-level Manifest while preserving the packages is forbidden. Deletion of an entire category is not. ECLASS (new) ~~~~~~~~~~~~ - uses _CRIT. - This type shall be used for all eclasses only. DATA (new) ~~~~~~~~~~ - uses _CRIT. - The DATA type shall be used for all files that directly affect the package manager, such as metadata/cache/* and profiles/. EXEC (new) ~~~~~~~~~~ - uses _CRIT. - If the file gets sourced, executed, or causes a change (patches) in how something is sourced or executed, it belongs in the EXEC filetype. - This filetype should be used for the scripts directories of a repository for important files. - This filetype is not limited to being used in the files/ subdirectory. OTHER (new) ~~~~~~~~~~~ - uses _CRIT. - All other files that are not covered by another type should be considered as 'OTHER'. - Any further new filetypes should be introduced to subtract files from the 'OTHER' set. - If a package manager runs into a unknown Manifest2 type, it should be treated as 'OTHER'. On Bloat -------- If repeated use of a common path prefix is considered a bloat problem, a Manifest file should be added inside the common directory, however this should not be done blindly, as bloat by inodes is more significant for the majority of use cases. See also [#GLEP58] on size reductions of Manifests. Chosing a filetype ------------------ 1. matches ``Manifest`` => MANIFEST, stop. 2. matches ``*.ebuild`` => EBUILD, stop. 3. matches ``*.eclass`` => ECLASS, stop. 4. listed in SRC_URI => DIST, stop. 5. matches ``files/*`` => AUX, continue [see note]. 6. matches any of ``*.sh``, ``*.bashrc``, ``*.patch``, ... => EXEC, stop. 7. matches any of ``metadata/cache/*``, ``profiles/``, ``package.*``, ``use.mask*``, ... => DATA, stop. 8. matches any of ``ChangeLog``, ``metadata.xml``, ``*.desc``, ... => MISC, stop. 9. not matched by any other rule => OTHER, stop. The logic behind 5, 6, 7 is ensuring that every item that by it's presence or absence may be dangerous should always be treated strictly. (Consider epatch given a directory of patches ``${FILESDIR}/${PV}/``, where it blindly includes them, or alternatively, the package.mask file or a profile being altered/missing). The above lists of file patterns are not intended to be exhaustive, but merely demonstrative. Note: The AUX entries should only be generated if we are generating a compatible Manifest that supports older versions of Portage. They should be generated along with the new type. Backwards Compatibility ======================= For generation of existing package Manifests, the AUX entries must continue to be present for the standard Portage deprecation cycle. The new entries may be included already in all Manifest files, as they will be ignored by older Portage versions. Over time, ECLASS, DATA, EXEC, OTHER may replace the existing AUX type. The adoption of this proposal does also affect [#GLEP58] as part of this GLEP series, however this GLEP was an offset of the research in that GLEP. Thanks to ========= I'd like to thank the following people for input on this GLEP. - Marius Mauch (genone) & Zac Medico (zmedico): Portage Manifest2 References ========== .. [#GLEP44] Mauch, M. (2005) GLEP44 - Manifest2 format. http://www.gentoo.org/proj/en/glep/glep-0044.html Copyright ========= Copyright (c) 2007-2010 by Robin Hugh Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0. vim: tw=72 ts=2 expandtab: [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] GLEP61 - Manifest2 compression 2010-01-31 9:20 [gentoo-dev] Tree-signing GLEPs update Robin H. Johnson ` (2 preceding siblings ...) 2010-01-31 10:01 ` [gentoo-dev] GLEP60 - Manifest2 filetypes Robin H. Johnson @ 2010-01-31 10:04 ` Robin H. Johnson 2010-02-08 1:02 ` Brian Harring 2010-01-31 10:11 ` [gentoo-dev] Tree-signing GLEPS review notes Robin H. Johnson 4 siblings, 1 reply; 16+ messages in thread From: Robin H. Johnson @ 2010-01-31 10:04 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 392 bytes --] Changes: - This GLEP can stand independently of GLEP58. - Add XZ to compression types list. - Move cutoff to 32KiB. Provide size example w/ 32KiB+gzip. - Split specification into generation and validation. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #1.2: glep-0061.txt --] [-- Type: text/plain, Size: 5653 bytes --] GLEP: 61 Title: Manifest2 compression Version: $Revision: 1.6 $ Last-Modified: $Date: 2010/01/31 09:55:43 $ Author: Robin Hugh Johnson <robbat2@gentoo.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 44 Created: July 2008 Updated: October 2008, January 2010 Updates: 44 Post-History: December 2009, January 2010 Abstract ======== Deals with compression of large Manifest2 files. Motivation ========== With the introduction of MetaManifest, and full-tree Manifest coverage, we are faced with the possibility of having very large Manifests. Preliminary experiments with MetaManifest, show that with just the existing per-package Manifests, the full MetaManifest (top-level only, no first-level sub directories), for a tree including metadata/, exceeds 8MiB in size. Applying common compression can achieve a 50-60% reduction in this size. Additionally, some of the larger already-existing Manifests in the tree can also be reduced. This GLEP is not mandatory for the tree-signing specification, but instead helps to cut down the size impact of large Manifest2 files, some of which are already present in the tree. As such, it is also able to stand on it's own. Specification ============= Creation of compressed Manifests: --------------------------------- 32KiB is suggested as a arbitrary cut-off point to start generating compressed Manifest2 files. The compression must only applied during the creation of a tree intended for end users. No Manifests stored in a VCS should be compressed in the VCS. For the main gentoo-portage tree, this means that the compressed Manifests should be generated using the CVS to Rsync process. The Manifest compression process is required to ensure that inconsistent compressed versions do not exist. Validation of Manifests: ------------------------ When searching for a Manifest2 file, if the basename form does not exist, the package manager should search in the same location using common compressed suffixes, and use the compressed file in place of the Manifest2. gzip, bzip2, lzma, xz should all be supported if available on the given platform. In the case that multiple versions exist, the package manager should simply pick one - they should be identical, differing only in compression. Example Results with a 32KiB cut-off, gzip algorithm ==================================================== As of 2010/01/30, the suggested cut-off would impact the following 21 existing Manifests, for a saving of nearly 900KiB:: Size Path 65788 app-doc/linux-gazette/Manifest 75739 app-office/openoffice-bin/Manifest 40534 app-text/texlive-core/Manifest 41710 dev-texlive/texlive-bibtexextra/Manifest 38197 dev-texlive/texlive-documentation-english/Manifest 129610 dev-texlive/texlive-fontsextra/Manifest 36022 dev-texlive/texlive-humanities/Manifest 686118 dev-texlive/texlive-latexextra/Manifest 43392 dev-texlive/texlive-latexrecommended/Manifest 33375 dev-texlive/texlive-mathextra/Manifest 39781 dev-texlive/texlive-pictures/Manifest 69567 dev-texlive/texlive-pstricks/Manifest 75460 dev-texlive/texlive-publishers/Manifest 50879 dev-texlive/texlive-science/Manifest 36711 kde-base/kde-l10n/Manifest 36539 media-gfx/bootsplash-themes/Manifest 33058 net-fs/autofs/Manifest 39781 www-client/firefox-bin/Manifest 48983 www-client/icecat/Manifest 60213 www-client/mozilla-firefox/Manifest 39065 x11-themes/gkrellm-themes/Manifest Additionally, with the MetaManifest proposal, the following new manifests would also be compressed, for a saving of nearly 4MiB:: Size Path 33442 app-admin/Manifest 71073 app-dicts/Manifest 35923 app-emacs/Manifest 45808 app-misc/Manifest 50169 app-text/Manifest 112786 dev-java/Manifest 65581 dev-libs/Manifest 42619 dev-lisp/Manifest 182163 dev-perl/Manifest 96198 dev-python/Manifest 58963 dev-ruby/Manifest 59736 dev-util/Manifest 58338 eclass/Manifest 55749 kde-base/Manifest 110064 licenses/Manifest 35262 media-gfx/Manifest 53995 media-libs/Manifest 55607 media-plugins/Manifest 71911 media-sound/Manifest 34835 media-video/Manifest 5747849 metadata/Manifest 47452 net-analyzer/Manifest 65989 net-misc/Manifest 316787 profiles/Manifest 67784 sys-apps/Manifest 48971 x11-misc/Manifest 41475 x11-plugins/Manifest Backwards Compatibility ======================= The package Manifests should also be maintained as ONLY uncompressed in CVS. For processing of all existing per-package Manifests, if compression is used, it should be done in parallel to the existing Manifests, to provide for a changeover period. Newer versions of Portage may later choose to exclude all non-compressed Manifests during emerge --sync if compressed versions are guaranteed to exist on the servers. MetaManifests may come into existence as compressed from the start, as do not have an backwards compatibility issues. As a side note, this breaks all manual interaction with Manifests such as grep, and so should only be applied to large Manifest2 files, such as the MetaManifest. References ========== .. [#GLEP44] Mauch, M. (2005) GLEP44 - Manifest2 format. http://www.gentoo.org/proj/en/glep/glep-0044.html Copyright ========= Copyright (c) 2008-2010 by Robin Hugh Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0. vim: tw=72 ts=2 expandtab: [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP61 - Manifest2 compression 2010-01-31 10:04 ` [gentoo-dev] GLEP61 - Manifest2 compression Robin H. Johnson @ 2010-02-08 1:02 ` Brian Harring 2010-02-08 5:23 ` Robin H. Johnson 0 siblings, 1 reply; 16+ messages in thread From: Brian Harring @ 2010-02-08 1:02 UTC (permalink / raw To: gentoo-dev; +Cc: robbat [-- Attachment #1: Type: text/plain, Size: 650 bytes --] On Sun, Jan 31, 2010 at 10:04:40AM +0000, Robin H. Johnson wrote: > Changes: > - This GLEP can stand independently of GLEP58. > - Add XZ to compression types list. > - Move cutoff to 32KiB. Provide size example w/ 32KiB+gzip. > - Split specification into generation and validation. > One concern w/ this glep- the intention seems to be to reduce on disk space requirements but the addition of compression raises questions for rsync transferance of the manifests. Have you done any testing to quantify how much of an increase in rsync bandwidth this will add? Specifically thinking about the metamanifest on this one. ~Brian [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP61 - Manifest2 compression 2010-02-08 1:02 ` Brian Harring @ 2010-02-08 5:23 ` Robin H. Johnson 2010-02-08 5:50 ` Brian Harring 0 siblings, 1 reply; 16+ messages in thread From: Robin H. Johnson @ 2010-02-08 5:23 UTC (permalink / raw To: gentoo-dev On Sun, Feb 07, 2010 at 05:02:22PM -0800, Brian Harring wrote: > On Sun, Jan 31, 2010 at 10:04:40AM +0000, Robin H. Johnson wrote: > > Changes: > > - This GLEP can stand independently of GLEP58. > > - Add XZ to compression types list. > > - Move cutoff to 32KiB. Provide size example w/ 32KiB+gzip. > > - Split specification into generation and validation. > One concern w/ this glep- the intention seems to be to reduce on disk > space requirements but the addition of compression raises questions > for rsync transferance of the manifests. > > Have you done any testing to quantify how much of an increase in rsync > bandwidth this will add? Specifically thinking about the metamanifest > on this one. The top-level MetaManifest, in the case of fully split (eg a Manifest in every 1st-level directory $CAT/Manifest and the other dirs), is only 33KiB. 21 existing packages have Manifests larger than 32KiB, texlive stuff come in the worst here. I do agree, that depending on the block alignment, there is an increase in transfer size in some cases, but I have not conducted rigorous tests to work out long-term statistics on changes. The more aggressively that Manifests are added to each subdirectory tree, the less Manifest2 compression is actually required, as the individual Manifests are more likely to fit within the size limit. With the 1st-level case again, here's a size count breakdown for the new (Meta)Manifests: >=32KiB: 27 >=64KiB: 10 >=128KiB: 3 (dev-perl @ 179KiB, metadata/ @ 5.2MiB, profiles/ @ 300KiB) I think the best course of action is to end up generating the compressed MetaManifests when we start generated the MetaManifests themselves, but not placing them into the tree yet. Instead simply use them to measure rsync transfer size impact on the generation server and produce statistics to see if the cutoff could benefit from being altered, or if the disk space should be wasted in favour of smaller transfer size. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] GLEP61 - Manifest2 compression 2010-02-08 5:23 ` Robin H. Johnson @ 2010-02-08 5:50 ` Brian Harring 0 siblings, 0 replies; 16+ messages in thread From: Brian Harring @ 2010-02-08 5:50 UTC (permalink / raw To: gentoo-dev; +Cc: robbat2 [-- Attachment #1: Type: text/plain, Size: 1567 bytes --] On Mon, Feb 08, 2010 at 05:23:03AM +0000, Robin H. Johnson wrote: > On Sun, Feb 07, 2010 at 05:02:22PM -0800, Brian Harring wrote: > > On Sun, Jan 31, 2010 at 10:04:40AM +0000, Robin H. Johnson wrote: > > > Changes: > > > - This GLEP can stand independently of GLEP58. > > > - Add XZ to compression types list. > > > - Move cutoff to 32KiB. Provide size example w/ 32KiB+gzip. > > > - Split specification into generation and validation. > > One concern w/ this glep- the intention seems to be to reduce on disk > > space requirements but the addition of compression raises questions > > for rsync transferance of the manifests. > > > > Have you done any testing to quantify how much of an increase in rsync > > bandwidth this will add? Specifically thinking about the metamanifest > > on this one. > > I think the best course of action is to end up generating the compressed > MetaManifests when we start generated the MetaManifests themselves, but > not placing them into the tree yet. Instead simply use them to measure > rsync transfer size impact on the generation server and produce > statistics to see if the cutoff could benefit from being altered, or if > the disk space should be wasted in favour of smaller transfer size. Works for me- I do strongly suspect that if we use compression we'll be purely trading disk space decrease for the cost of transfering each changed compressed manifest in full though... rsync + compression do not get along at all. Either way, stats would be useful when you've got time. ~brian [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Tree-signing GLEPS review notes 2010-01-31 9:20 [gentoo-dev] Tree-signing GLEPs update Robin H. Johnson ` (3 preceding siblings ...) 2010-01-31 10:04 ` [gentoo-dev] GLEP61 - Manifest2 compression Robin H. Johnson @ 2010-01-31 10:11 ` Robin H. Johnson 4 siblings, 0 replies; 16+ messages in thread From: Robin H. Johnson @ 2010-01-31 10:11 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1166 bytes --] The GLEP numbering represents the order in which I wrote the GLEPs. It originally started off as just two very large GLEPs. The informational GLEP and the changes GLEP. I split it out BECAUSE I realized that many of the parts should stand on their own merits. For anybody looking for a hand in reviewing these, I suggest tackling them in the following order: Phase 0, background: -------------------- GLEP57 - Security overview Phase 1, isolated improvements to Manifest2: -------------------------------------------- GLEP59 - Manifest2 hashes GLEP61 - Manifest2 compression Phase 2, adding to Manifest2 infrastructure: -------------------------------------------- GLEP60 - Manifest2 filetypes Phase 3, Infra->User security: ------------------------------ GLEP58 - MetaManifest Phase 4, Dev->infra security: ----------------------------- I still need to write the following: GLEPxx - Developer Process Security GLEPxx - GnuPG Policies and Handling -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 [-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2010-02-08 5:52 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-01-31 9:20 [gentoo-dev] Tree-signing GLEPs update Robin H. Johnson 2010-01-31 9:48 ` [gentoo-dev] GLEP58 - MetaManifest Robin H. Johnson 2010-02-02 6:27 ` Denis Dupeyron 2010-02-02 7:35 ` Robin H. Johnson 2010-01-31 9:57 ` [gentoo-dev] GLEP59 - Manifest2 hashes Robin H. Johnson 2010-02-01 5:05 ` Robin H. Johnson 2010-02-01 8:23 ` Doug Goldstein 2010-02-02 6:06 ` Denis Dupeyron 2010-02-04 2:57 ` Robin H. Johnson 2010-02-02 6:09 ` Robin H. Johnson 2010-01-31 10:01 ` [gentoo-dev] GLEP60 - Manifest2 filetypes Robin H. Johnson 2010-01-31 10:04 ` [gentoo-dev] GLEP61 - Manifest2 compression Robin H. Johnson 2010-02-08 1:02 ` Brian Harring 2010-02-08 5:23 ` Robin H. Johnson 2010-02-08 5:50 ` Brian Harring 2010-01-31 10:11 ` [gentoo-dev] Tree-signing GLEPS review notes Robin H. Johnson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox