-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Darian,

On Sunday, November 2, 2003, at 07:27 PM, Darian Lanx wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Wouldn't it be useful to include a PGP Key id in this field.
email addresses are somewhat transient whereas PGP/GPG keys are not. If the maintainer's email address once changed it could be still located via the PGP key if changes in the address are properly sent to the key servers. But this should normally be the case. If this policy would be established another field could carry a PGP signature for the rest of the info file. See the attached .info-PROPOSAL file.

Hello Mister Prohaska.



I'm young enough to be called Steffen ;-)


First of all thank you for submitting a new package, but please submit such information to the package submission tracker in the future. Not because we do not value you work, but to keep such traffic off the list and thus to a minimum. You may find the tracker at this URL
http://sourceforge.net/tracker/?atid=414256&group_id=17203



Thanks for pointing me to this tracker. I checked at the description of the mailing list:


>fink-devel Mailing List

>The main purpose of the fink-devel list is to coordinate the package maintainers efforts. Still, anyone is welcome to subscribe to the list and >listen to what goes on behind the scenes. If you want to package your favourite piece of software for Fink, this is the place to go. People >without CVS commit access can post their package descriptions on the list to have them reviewed and added to Fink.

Perhaps you could add a comment pointing to the sourceforge tracker. Until today I didn't go into the details of sourceforge and had to create my sourceforge account to submit the package to the tracker. Well, now I'm a member and submitted my first issue.

When submitting an issue there's a short note on attaching the info and patch file to the same item. --- .info and .patch files). If your package needs a patch file, please attach it to the same item. --- . It's only possible to submit one file. Therefore I created a tar.gz. If this is the right way perhaps a short note would also be appropriate.

regarding your GPG proposal I have a few things to remark. I have thought about adding gpg signatures to the info files and then to the .debs for a long time but that introduces some logical issues. First of all gpg is not something that Mac os X provides per se (unless that changed in 10.3) and our typical user base has probably no understanding of what GPG is and does. Thus we will have to make the process as automated as we can, handling most of the common failures. This is not a trivial issues, especially since I am not sure how to integrate the gpg framework itself into fink. There are numerous Perl Modules, even one that inplements OpenGPG in pure perl, yet all those modules have dependencies. Those would have to be made essential packages, so that they are present whenever fink is first installed on a system.


Your absolutely right. It's not simple.


The next issue is trust. While the main developers _could_ theoretically meet to sign their gpg keys, it is pretty impossible for all of the Fink contributors to come together and sign their keys, thus a signed package does not really mean anything to me unless I can trust the key.

If you have ideas how to solve this, please do send them in. I am absolutely in favour of signing the packages and/or info files.

But nontheless some remarks. A thing a signature could provide is the guarantee that the package maintainer really packed what you're using. It means that nobody except for the package maintainer can change things. This might be helpful or annoying depending on the viewpoint. E.g. it's not easily possible for the main developers to fix package descriptions or patches because the only way to do so is to take over the package maintenance otherwise she's not able to provide a consistent signature -- There might be details about this, but in principle. This could be helpful to detect unauthorized changes in the cvs repository or in one of the trackers or on one of the mirrors. I'm not paranoid but there have been cases like this. If a .info/.patch file is not working it's guaranteed that you can blame the right person for this.


To get this working another step would be to use md5sum not only on the package source but also on the patch files. If all the fields (including the md5 sums of all sources and the patches and the maintainer together with the gpg key id) are signed by the maintainer this signature assures that you're getting exactly the source the maintainer provided. If you don't trust the maintainer this still doesn't mean you should trust package. But at least it is assured that if you blame the maintainer for errors your talking to the right person.

Therefore, it is the basis. Trust is the second step.

/steffen

- --
PGP Public Key: http://www.zib.de/prohaska/prohaska.pgp
Key id: 0xDA749299
Key fingerprint: 8B59 83A8 A43D E0E2 DEDB  D479 3157 2FEA DA74 9299

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQE/pXqwMVcv6tp0kpkRAnwCAJ9LDbjYW8yZqRnkVY8foi7ImGQMVwCfRrDq
SDx63FOd4MhoG/fFkhl7Fp0=
=bW6x
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to