Menu
▾
▴
cryptoapi-devel
|
From: Justin C. <ju...@po...> - 2002-03-04 17:04:43
|
Hi everyone, I've volunteered to help out the CryptoAPI project by taking the time to put the CryptoAPI patches in the SourceForge sites' "Files" section so people can download them directly from there, and might be able to help here and there with other CryptoAPI-SF.net things. As well as the kernel patches, I feel it's worth putting the CryptoAPI's util-linux patches on the site, but am not sure whether both the 2.11i and 2.11n one's should be there, or just the 2.11n ones. From memory, I've been using the 2.11i ones and haven't really looked at the 2.11n ones. Would like people's opinions on this, etc. It should make for a good next step, and we can see if this helps expand the userbase of people using crypto stuff with Linux (appropriately), and also find out if this makes it easier for the people already using cryptoAPI to keep up to date. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 17:34:17
|
On Mon, 2002-03-04 at 18:02, Justin Clift wrote: > As well as the kernel patches, I feel it's worth putting the CryptoAPI's > util-linux patches on the site, but am not sure whether both the 2.11i > and 2.11n one's should be there, or just the 2.11n ones. From memory, > I've been using the 2.11i ones and haven't really looked at the 2.11n > ones. Would like people's opinions on this, etc. I'm not really opposed to it, but on the other hand maybe some link to ftp.kernel.org for the patch-int's would be better, since there we can get those patches gpg-signed w/ kernel.org signature.... while on sourceforge it would require some more work to reliably verify the integrity of the sources... btw, keep in mind, that the new planned distribution style will try to become version indepent, i.e. you download a tar-ball and it does the required patching of your kernel automatically; thus we should be able to provide many kernel versions with the latest API... this will be a major breakthrough in versioning wrt to the international kernel patch... =20 > It should make for a good next step, and we can see if this helps expand > the userbase of people using crypto stuff with Linux (appropriately), > and also find out if this makes it easier for the people already using > cryptoAPI to keep up to date. btw, some ready to use util-linux crypto-enhanced rpm packages would surely boost the user base... as most distros use rpm's today... next night might be ready to use kernel rpms (at least for the most common distros), that might be another killer application... I'd have a strange feeling, if I were to trust binaries I didn't compile myself... but well, not all users are at this level of paranoia... :-) regards, --=20 Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Kyle M. <ky...@de...> - 2002-03-04 20:16:51
|
On Mon, Mar 04, 2002 at 06:34:05PM +0100, Herbert Valerio Riedel wrote: > btw, some ready to use util-linux crypto-enhanced rpm packages would > surely boost the user base... as most distros use rpm's today... > i feel it would also be worth mentioning that debian ships these packages by default. perhaps other distribution vendors could be convinced to do the same. (well, those that are based in the free world, where hooks to crypto doesn't necessarily mean implements crypto) -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 21:15:12
|
On Mon, 2002-03-04 at 21:16, Kyle McMartin wrote: > On Mon, Mar 04, 2002 at 06:34:05PM +0100, Herbert Valerio Riedel wrote: > > btw, some ready to use util-linux crypto-enhanced rpm packages would > > surely boost the user base... as most distros use rpm's today... > i feel it would also be worth mentioning that debian ships these > packages by default. perhaps other distribution vendors could be > convinced to do the same. (well, those that are based in the free world, > where hooks to crypto doesn't necessarily mean implements crypto) well, in order to do so, we should convince them in the first place, that cryptoapi's cryptoloop and the crypotapi itself is a mature piece of code... the unclear state of maintenance has earned this project a bad reputation; and jari's negative press (which only in part was true) hasn't helped much either...=20 on the other hand, we have the benefit of being the more or less official crypto extension for the linux kernel... should we lose this as well, we can give up completely... :-/ regards, --=20 Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
Re: [CryptoAPI-devel] Is keeping the patches available through theSF.net
"Files" section beneficial?
From: Justin C. <ju...@po...> - 2002-03-05 00:51:35
|
Hi Herbert, Herbert Valerio Riedel wrote: > > On Mon, 2002-03-04 at 18:02, Justin Clift wrote: > > As well as the kernel patches, I feel it's worth putting the CryptoAPI's > > util-linux patches on the site, but am not sure whether both the 2.11i > > and 2.11n one's should be there, or just the 2.11n ones. From memory, > > I've been using the 2.11i ones and haven't really looked at the 2.11n > > ones. Would like people's opinions on this, etc. > > I'm not really opposed to it, but on the other hand maybe some link to > ftp.kernel.org for the patch-int's would be better, since there we can > get those patches gpg-signed w/ kernel.org signature.... while on > sourceforge it would require some more work to reliably verify the > integrity of the sources... I can see what you mean with that. Sounds like the web-page needs to have a few more links, as I don't think we can put links from the "Files" section on the sourceforge site. I don't understand why we can't have the the patches signed with the gpg kernel.org signature, wherever they are for download. Then again, I haven't used gpg which probably explains why. :) <snip> > regards, > -- > Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 > Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key > GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F > 4142 > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: PGP Armored File (application/x-unknown-content-type-PGP Armored File) > Description: This is a digitally signed message part -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
Re: [CryptoAPI-devel] Is keeping the patches available through
theSF.net "Files" section beneficial?
From: Herbert V. R. <hv...@hv...> - 2002-03-05 09:56:58
|
On Tue, 5 Mar 2002, Justin Clift wrote: > I can see what you mean with that. Sounds like the web-page needs to > have a few more links, as I don't think we can put links from the > "Files" section on the sourceforge site. > > I don't understand why we can't have the the patches signed with the gpg > kernel.org signature, wherever they are for download. Then again, I > haven't used gpg which probably explains why. :) ...silly me, the sigs can just be copied from kernel.org C:-) ...forget that argument... :) there's only one thing now... the API changed a little bit for the unofficial testing patches, and only now has changed back to a backward compatible means... so please wait a little bit before adding files... regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Justin C. <ju...@po...> - 2002-03-05 12:37:11
|
Hi Herbert, Herbert Valerio Riedel wrote: > > On Tue, 5 Mar 2002, Justin Clift wrote: > > > I can see what you mean with that. Sounds like the web-page needs to > > have a few more links, as I don't think we can put links from the > > "Files" section on the sourceforge site. > > > > I don't understand why we can't have the the patches signed with the gpg > > kernel.org signature, wherever they are for download. Then again, I > > haven't used gpg which probably explains why. :) > ...silly me, the sigs can just be copied from kernel.org C:-) > > ...forget that argument... :) Heh Heh Heh That's alright. At least it means it won't be harder to give people the ability to verify the files they've got. :) > > there's only one thing now... the API changed a little bit for the > unofficial testing patches, and only now has changed back to a backward > compatible means... so please wait a little bit before adding files... Ummm... oops. I've just added most of them. Still wondering how I should put the loop-* files up, etc. What I've done so far is have add packages to the existing "cryptoapi" release. And each package is a group of files. i.e. : 2.4.18.1 patch-int-2.4.18.1.bz2 patch-int-2.4.18.1.bz2.sign patch-int-2.4.18.1.gz patch-int-2.4.18.1.gz.sign 2.4.18.0 patch-int-2.4.18.0.bz2 patch-int-2.4.18.0.bz2.sign patch-int-2.4.18.0.gz patch-int-2.4.18.0.gz.sign 2.4.17.0 patch-int-2.4.17.0.bz2 patch-int-2.4.17.0.bz2.sign patch-int-2.4.17.0.gz patch-int-2.4.17.0.gz.sign I'm thinking I should copy the loop-hvr-2.4.16.0.patch file to each of these, just because it'll make it easier for newcomers to understand, and probably the loop-jari-2.4.16.0.patch too. i.e. 2.4.18.1 loop-hvr-2.4.18.1.patch loop-jari-2.4.18.1.patch patch-int-2.4.18.1.bz2 patch-int-2.4.18.1.bz2.sign patch-int-2.4.18.1.gz patch-int-2.4.18.1.gz.sign 2.4.18.0 loop-hvr-2.4.18.0.patch loop-jari-2.4.18.0.patch patch-int-2.4.18.0.bz2 patch-int-2.4.18.0.bz2.sign patch-int-2.4.18.0.gz patch-int-2.4.18.0.gz.sign 2.4.17.0 loop-hvr-2.4.17.0.patch loop-jari-2.4.17.0.patch patch-int-2.4.17.0.bz2 patch-int-2.4.17.0.bz2.sign patch-int-2.4.17.0.gz patch-int-2.4.17.0.gz.sign Does adding in these patches (and renumbering them so it's easy to understand) make sense to you? :-) Regards and best wishes, Justin Clift > regards, > -- > Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 > Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key > GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Kyle M. <ky...@de...> - 2002-03-04 21:24:59
|
On Mon, Mar 04, 2002 at 10:15:00PM +0100, Herbert Valerio Riedel wrote: > well, in order to do so, we should convince them in the first place, > that cryptoapi's cryptoloop and the crypotapi itself is a mature piece > of code... > i guess making the ciphers endian independant is the first issue... > the unclear state of maintenance has earned this project a bad > reputation; and jari's negative press (which only in part was true) > hasn't helped much either... > i have a question about this, does cryptoapi replace kernel-int or does kernel-int still exist? > on the other hand, we have the benefit of being the more or less > official crypto extension for the linux kernel... should we lose this as > well, we can give up completely... :-/ > nod, i guess we'll have to make sure it doesn't :) - k -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 21:35:19
|
On Mon, 2002-03-04 at 22:25, Kyle McMartin wrote: > > well, in order to do so, we should convince them in the first place, > > that cryptoapi's cryptoloop and the crypotapi itself is a mature piece > > of code... > i guess making the ciphers endian independant is the first issue... I fixed 4 lately, rc5, rc6, blowfish and another aes finalist I don't remember....=20 I remember issues with idea, dfc and maybe one else (see my last mail regarding this issue)... =20 > > the unclear state of maintenance has earned this project a bad > > reputation; and jari's negative press (which only in part was true) > > hasn't helped much either...=20 > i have a question about this, does cryptoapi replace kernel-int or does > kernel-int still exist? cryptoapi is just a name for the tarball packaging I chosed, since nonpatch-int sounded too stupid for a non-patch distribution ;) =20 also cryptoapi seemed a good buzzword... :-) i.e. patch-int and cryptoapi are supposed to mean the same... should we get cryptoapi-0.1.0.tar.gz (or whatever version it may become) ready the patch-int's will have to carry names as patch-int-2.4.18-0.1.0.gz ...in order to better reflect the versioning scheme... regards, --=20 Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X