FAQ
While I'm thinking about it I thought I'd post the URL for the OSD spec.

http://www.w3.org/TR/NOTE-OSD

While reading it two things were in question; how will it fit into the
CPAN and how do we get people not only to use it but use it consistently.
It's food for thought anyway.

Another thought I had was to consider hiring someone who is a professional
catalogue librarian who may specialise in technical publications. I'm
certain the MLA could help us find such a person and I would be willing to
offer the prize money to pay for it. A professional and disinterested
opinion from someone who does this for a living could prove to be very
helpful.

Also, if anyone has suggestions for new questions for the FAQ, etc. I've
decided that this weeks procrastination tool will be to polish up the FAQ
to make it easier to read and offer a pod and pdf version of it as well.

e.

Search Discussions

  • Jarkko Hietaniemi at Jul 26, 2000 at 8:15 pm

    On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
    While I'm thinking about it I thought I'd post the URL for the OSD spec.

    http://www.w3.org/TR/NOTE-OSD

    While reading it two things were in question; how will it fit into the
    CPAN and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    People looking at OSD should probably also look at what metadata other
    packaging systems (rpm, deb, pkgadd, ...) define and use.

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Simon Cozens at Jul 27, 2000 at 3:47 am

    On Wed, Jul 26, 2000 at 11:15:03PM +0300, Jarkko Hietaniemi wrote:
    On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
    While I'm thinking about it I thought I'd post the URL for the OSD spec.

    http://www.w3.org/TR/NOTE-OSD

    While reading it two things were in question; how will it fit into the
    CPAN and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    People looking at OSD should probably also look at what metadata other
    packaging systems (rpm, deb, pkgadd, ...) define and use.
    While we're at it, I'll throw in Trove:
    http://www.tuxedo.org/~esr/trove/


    --
    COBOL is for morons.
    -- E.W. Dijkstra
  • Adam Turoff at Jul 27, 2000 at 5:28 am

    On Thu, Jul 27, 2000 at 12:46:13PM +0900, Simon Cozens wrote:
    On Wed, Jul 26, 2000 at 11:15:03PM +0300, Jarkko Hietaniemi wrote:
    People looking at OSD should probably also look at what metadata other
    packaging systems (rpm, deb, pkgadd, ...) define and use.
    While we're at it, I'll throw in Trove:
    http://www.tuxedo.org/~esr/trove/
    I don't think Trove was ever implemented, or ever will be. The ideas
    discussed in Trove have manifest themselves in sourceforge though.

    Z.
  • Simon Cozens at Jul 27, 2000 at 5:42 am
    [Eric: This is from a list discussing how to add classification to the
    Comprehensive Perl Archive Network]
    On Thu, Jul 27, 2000 at 01:28:26AM -0400, Adam Turoff wrote:
    On Thu, Jul 27, 2000 at 12:46:13PM +0900, Simon Cozens wrote:
    People looking at OSD should probably also look at what metadata other
    packaging systems (rpm, deb, pkgadd, ...) define and use.
    While we're at it, I'll throw in Trove:
    http://www.tuxedo.org/~esr/trove/
    I don't think Trove was ever implemented, or ever will be. The ideas
    discussed in Trove have manifest themselves in sourceforge though.
    I think it's a little stronger than that: trove-dev doesn't tell me
    much but I believe that Sourceforge is using trove itself. I registered
    a project on Sourceforge today, and that wants me to provide a trove
    classification, so it looks like they're certainly keeping a trove
    database of some sort. Trove *is* alive.

    The trick is how to ensure that we don't end up with a bunch of separate
    databases, and I'm not sure how we're supposed to avoid that. If we go
    the trove route (and, yes, I acknowledge completely this is totally
    undecided, but I'd like to very strongly suggest it) I don't know
    whether we'd be adding things from our database to Sourceforge's, or
    if there's a metaindex.

    Trove does certainly contain all the metadata elements we're likely to
    need, by design, and when apps.perlhacker
    (http://perlhacker.org/perlhacker.html) actually happens, I'm planning
    to use trove classification in that.

    It's an option for CPAN, but not one that I'm prepared to pretend I
    fully understand right now.

    Simon
    --
    Also note that i knew _far_ more about the people that call address
    mungers names like 'lusers', 'egoists' or try to make luser giraffes.
    -- Megahal (trained on asr), 1998-11-06
  • Graham Barr at Jul 27, 2000 at 12:21 pm

    On Thu, Jul 27, 2000 at 12:46:13PM +0900, Simon Cozens wrote:
    On Wed, Jul 26, 2000 at 11:15:03PM +0300, Jarkko Hietaniemi wrote:
    On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
    While I'm thinking about it I thought I'd post the URL for the OSD spec.

    http://www.w3.org/TR/NOTE-OSD

    While reading it two things were in question; how will it fit into the
    CPAN and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    People looking at OSD should probably also look at what metadata other
    packaging systems (rpm, deb, pkgadd, ...) define and use.
    While we're at it, I'll throw in Trove:
    http://www.tuxedo.org/~esr/trove/
    Trove is a database which requires the user to enter data via the web. In effect
    it is trying to be a general _source_ archive.

    This does not go far enough for what is needed for CPAN.

    We need to be able to know about binary distributions and connect them to the
    source distribution. What dependancies does each distribution have on
    any other perl modules. But most of all be as little work on the developer
    as possible.

    Graham.
  • Graham Barr at Jul 27, 2000 at 12:17 pm

    On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
    While I'm thinking about it I thought I'd post the URL for the OSD spec.

    http://www.w3.org/TR/NOTE-OSD

    While reading it two things were in question; how will it fit into the
    CPAN
    This is TBD. But what I could see is an OSD directory in which OSDs are
    placed. On upload of a distribution it's OSD would be extracted and
    placed into the OSD directory.

    One thing that came up during the meeting was that there should be
    one OSD per dist which covers all implementatons. I was skeptical
    of this at the time, but now having thought a bit more I think it
    would work.
    and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    Well the generation of it would be part of makemaker. The really important
    stuff would be added done by makemaker. The author would then be able
    to add other info (like description, webpage etc) that would be of
    use to indexers.

    Graham.
  • Andreas J. Koenig at Jul 29, 2000 at 8:19 am

    On Thu, 27 Jul 2000 13:13:59 +0100, Graham Barr said:
    On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
    While I'm thinking about it I thought I'd post the URL for the OSD spec.

    http://www.w3.org/TR/NOTE-OSD

    While reading it two things were in question; how will it fit into the
    CPAN
    This is TBD. But what I could see is an OSD directory in which OSDs are
    placed. On upload of a distribution it's OSD would be extracted and
    placed into the OSD directory.
    One thing that came up during the meeting was that there should be
    one OSD per dist which covers all implementatons. I was skeptical
    of this at the time, but now having thought a bit more I think it
    would work.
    I'd really like to keep the way CPAN is working now, just start using
    well specified metadata for it. The OSD probably promises too much. In
    practice it (well, its cousin in law PPD) only has proofed working for
    one architecture -- or are there any other known places it ever was
    used?

    And probably PPD only works for that one architecture because we have
    CPAN.

    Seeing it from that perspective, the only merging needed would be an
    extraction into the modules/02packages.details.txt.gz file. For a
    first implementation this should be enough.

    XML databases seem to tend to become very large collections of data,
    like database dumps. We should not do too much preprocessing of them
    as any transformation can be regarded as redundant bloat.
    and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    Well the generation of it would be part of makemaker. The really important
    stuff would be added done by makemaker. The author would then be able
    to add other info (like description, webpage etc) that would be of
    use to indexers.
    I'd think, that the safer approach would be to add keywords to
    makemaker as needed and let makemaker write the OSD. That would help
    to catch errors early. Hand-written XML seems risky to me.

    --
    andreas
  • Graham Barr at Jul 30, 2000 at 6:51 pm

    On Sat, Jul 29, 2000 at 10:19:36AM +0200, Andreas J. Koenig wrote:
    On Thu, 27 Jul 2000 13:13:59 +0100, Graham Barr <gbarr@pobox.com> said:
    On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
    While I'm thinking about it I thought I'd post the URL for the OSD spec.

    http://www.w3.org/TR/NOTE-OSD

    While reading it two things were in question; how will it fit into the
    CPAN
    This is TBD. But what I could see is an OSD directory in which OSDs are
    placed. On upload of a distribution it's OSD would be extracted and
    placed into the OSD directory.
    One thing that came up during the meeting was that there should be
    one OSD per dist which covers all implementatons. I was skeptical
    of this at the time, but now having thought a bit more I think it
    would work.
    I'd really like to keep the way CPAN is working now, just start using
    well specified metadata for it. The OSD probably promises too much. In
    practice it (well, its cousin in law PPD) only has proofed working for
    one architecture -- or are there any other known places it ever was
    used?
    OSD can contain all the meta data we need. Merging is not strictly
    needed, we can use OSD without it. But to a large extent it does make
    sense. This is because the only parts different between two OSDs for
    the same distribution are the IMPLEMENTATION parts which describe which
    platform a givein distribution is for.
    And probably PPD only works for that one architecture because we have
    CPAN.
    At the moment I see it as completly separate. The PPD files point to
    somewhere else where the binary dists exist. Using OSd can bring CPAN
    and PPD back together.
    Seeing it from that perspective, the only merging needed would be an
    extraction into the modules/02packages.details.txt.gz file. For a
    first implementation this should be enough.
    I don't see the point in defining our own file format when there is an
    extensible one out there that can be used. The first place we need to
    get the meta data is into the distribution, which OSD can help with.
    Why then change the format to disribut it on CPAN, that surely does not
    make any sense.
    XML databases seem to tend to become very large collections of data,
    like database dumps. We should not do too much preprocessing of them
    as any transformation can be regarded as redundant bloat.
    It is one file for each source distribution uploaded. That can hardly
    be called large.
    and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    Well the generation of it would be part of makemaker. The really important
    stuff would be added done by makemaker. The author would then be able
    to add other info (like description, webpage etc) that would be of
    use to indexers.
    I'd think, that the safer approach would be to add keywords to
    makemaker as needed and let makemaker write the OSD. That would help
    to catch errors early. Hand-written XML seems risky to me.
    I think a template appraoch is more extensible. MakeMaker cannot know
    about everything that goes into the OSD file. OSD defines a way for people
    to add thier own tags. This would not be very easy from MakeMaker. IMO the
    user should have a template OSD which they fillout and then MakeMake reads
    this, adds whats needed and then writes a new OSD which the information
    it does know (version etc.) which is inluded in the distribution.

    Graham.
  • Andreas J. Koenig at Jul 30, 2000 at 8:33 pm

    On Sun, 30 Jul 2000 19:47:57 +0100, Graham Barr said:
    One thing that came up during the meeting was that there should be
    one OSD per dist which covers all implementatons. I was skeptical
    of this at the time, but now having thought a bit more I think it
    would work.
    I'd really like to keep the way CPAN is working now, just start using
    well specified metadata for it. The OSD probably promises too much. In
    practice it (well, its cousin in law PPD) only has proofed working for
    one architecture -- or are there any other known places it ever was
    used?
    OSD can contain all the meta data we need. Merging is not strictly
    needed, we can use OSD without it. But to a large extent it does make
    sense. This is because the only parts different between two OSDs for
    the same distribution are the IMPLEMENTATION parts which describe which
    platform a givein distribution is for.
    So only the IMPLEMENTATION and the RESULT (or MANIFEST) or so could be
    described in secondary (aka binary) distributions, accompanied by a
    pointer to the primary distribution.
    And probably PPD only works for that one architecture because we have
    CPAN.
    At the moment I see it as completly separate. The PPD files point to
    somewhere else where the binary dists exist. Using OSd can bring CPAN
    and PPD back together.
    Sure, this is an important goal that I'd like to achieve.

    But at the same time we should try to avoid the flaws in PPD. E.g. The
    idea to have author's credentials in the distribution data is against
    good old database rules to normalize data before storing them.
    Seeing it from that perspective, the only merging needed would be an
    extraction into the modules/02packages.details.txt.gz file. For a
    first implementation this should be enough.
    I don't see the point in defining our own file format when there is an
    extensible one out there that can be used.
    I have no doubt in XML as file format, this is certainly OK, and it is
    extensible. And the file format of 02packages' file will need to be
    supported for a while for backwards compatibility.

    Merejn has volunteered to suggest us something better for the
    aggregate files. Let's hear what he comes up with.
    The first place we need to
    get the meta data is into the distribution, which OSD can help with.
    Exactly, no argument here.
    Why then change the format to disribut it on CPAN, that surely does not
    make any sense.
    I'm not arguing for changing the format but to optimize it for what we
    are doing. The most urgent points I would like to see addressed are:

    - List of and checksums for all files in the distribution,

    - a signature

    - a list of namespaces used within the files that are being installed
    by this distribution

    - a list of version numbers
    XML databases seem to tend to become very large collections of data,
    like database dumps. We should not do too much preprocessing of them
    as any transformation can be regarded as redundant bloat.
    It is one file for each source distribution uploaded. That can hardly
    be called large.
    Sorry, I wasn't clear enough. I was talking about the collection of
    all (future) OSDs on CPAN and elsewhere.
    and how do we get people not only to use it but use it consistently.
    It's food for thought anyway.
    Well the generation of it would be part of makemaker. The really important
    stuff would be added done by makemaker. The author would then be able
    to add other info (like description, webpage etc) that would be of
    use to indexers.
    I'd think, that the safer approach would be to add keywords to
    makemaker as needed and let makemaker write the OSD. That would help
    to catch errors early. Hand-written XML seems risky to me.
    I think a template appraoch is more extensible. MakeMaker cannot know
    about everything that goes into the OSD file. OSD defines a way for people
    to add thier own tags. This would not be very easy from MakeMaker. IMO the
    user should have a template OSD which they fillout and then MakeMake reads
    this, adds whats needed and then writes a new OSD which the information
    it does know (version etc.) which is inluded in the distribution.
    Let me withdraw what I said. I think, it's OK as you suggest. But we
    should offer the user the option to not filling in anything into any
    file except into the Makefile.PL and leaving all the work to
    MakeMaker. That way we would have a very smooth transition path,
    higher acceptance, less intrusion into the developers' working place.

    Ideally, we would change what 'make dist' is doing now without asking
    the user to do anything.

    --
    andreas
  • Graham Barr at Jul 30, 2000 at 8:50 pm

    On Sun, Jul 30, 2000 at 10:32:57PM +0200, Andreas J. Koenig wrote:
    Let me withdraw what I said. I think, it's OK as you suggest. But we
    should offer the user the option to not filling in anything into any
    file except into the Makefile.PL and leaving all the work to
    MakeMaker. That way we would have a very smooth transition path,
    higher acceptance, less intrusion into the developers' working place.
    Sure. With no extra information the should get what make ppd does now.
    But they should be able to seed the file by giving a template.
    Ideally, we would change what 'make dist' is doing now without asking
    the user to do anything.
    Yes, I belive it should create the OSD file and include it, even though
    it is not specified in the MANIFEST. Maybe it should add it to the MANIFEST
    that is included if it is not specified in there already.

    Graham.
  • Elaine -HFB- Ashton at Jul 30, 2000 at 9:51 pm
    Graham Barr [gbarr@pobox.com] quoth:
    *>> Ideally, we would change what 'make dist' is doing now without asking
    *>> the user to do anything.
    *>
    *>Yes, I belive it should create the OSD file and include it, even though
    *>it is not specified in the MANIFEST. Maybe it should add it to the MANIFEST
    *>that is included if it is not specified in there already.

    It should be both unintrusive as well as easy to use for beginner and
    expert alike.

    This may be a good time to step back from the specific implementation
    details and ask 'What is the specific goal of this information?' or why do
    we want it, what problems will it solve and what benefits will we expect
    to reap from it?

    My only specific thought is that a library without a card catalogue is
    useless except for browsing as finding a book easily or at all is nearly
    impossible...and this reminds me of CPAN. Some form of index information
    contained in the module itself that can be tossed into a database would
    solve the growing muddle that is CPAN.

    If we can decide what information should be included first, the how will
    move along after that.

    What information should this metadata thingy contain?

    e.
  • Elaine -HFB- Ashton at Aug 1, 2000 at 7:52 pm
    Andreas J. Koenig [andreas.koenig@anima.de] quoth:
    *>
    *>I'm not arguing for changing the format but to optimize it for what we
    *>are doing. The most urgent points I would like to see addressed are:
    *>
    *>- List of and checksums for all files in the distribution,

    Could you elaborate on this a bit? What is the checksum good for, where
    would it be stored and could it be obsoleted by a cryptographic signature?

    *>- a signature
    *>- a list of namespaces used within the files that are being installed
    *> by this distribution
    *>- a list of version numbers

    I'd like to see a the dependancies and possibly a list of 'categories' and
    a unique catalogue number for each that would be assigned on upload.

    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???

    e.
  • Chris Nandor at Aug 1, 2000 at 9:00 pm

    At 14:50 -0500 2000.08.01, Elaine -HFB- Ashton wrote:
    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    What about binary distributions?

    --
    Chris Nandor | pudge@pobox.com | http://pudge.net/
    Andover.Net | chris.nandor@andover.net | http://slashcode.com/
  • Dan Sugalski at Aug 1, 2000 at 9:19 pm

    At 04:59 PM 8/1/00 -0400, Chris Nandor wrote:
    At 14:50 -0500 2000.08.01, Elaine -HFB- Ashton wrote:
    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    What about binary distributions?
    And XS code optional? (I'd really like to be able to have a function in
    both XS and perl, and let the core choose which one it wants. Makes
    serializing objects with their code possible)

    Dan

    --------------------------------------"it's like this"-------------------
    Dan Sugalski even samurai
    dan@sidhe.org have teddy bears and even
    teddy bears get drunk
  • Graham Barr at Aug 2, 2000 at 9:07 am

    On Tue, Aug 01, 2000 at 04:59:42PM -0400, Chris Nandor wrote:
    At 14:50 -0500 2000.08.01, Elaine -HFB- Ashton wrote:
    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    What about binary distributions?
    The OSD supports this. THis is one of my main reasons for wanting
    it. It will allow us to better associate binary and source distributions
    without relying on the distribution name.

    Graham.
  • Andreas J. Koenig at Aug 1, 2000 at 9:07 pm

    On Tue, 1 Aug 2000 14:50:19 -0500, elaine@chaos.wustl.edu (Elaine M. Ashton) said:
    Andreas J. Koenig [andreas.koenig@anima.de] quoth:
    *>
    *>I'm not arguing for changing the format but to optimize it for what we
    *>are doing. The most urgent points I would like to see addressed are:
    *>
    *>- List of and checksums for all files in the distribution,
    Could you elaborate on this a bit? What is the checksum good for, where
    would it be stored and could it be obsoleted by a cryptographic signature?
    My idea was to have the complete list of contained files, each with a
    checksum. This can be signed then. A signature that is produced this
    way can be included in the distribution file and doesn't need to be
    distributed separately. Distributing separately is considered annoying
    and errorprone.
    *>- a signature
    *>- a list of namespaces used within the files that are being installed
    *> by this distribution
    *>- a list of version numbers
    I'd like to see a the dependancies and possibly a list of 'categories' and
    We can just mentally go through the MakeMaker variables and put them
    in if they tend to be relevant. PREREQ_PM is very relevant. For
    categories we still have to decide on a categorisation scheme. It's
    not needed immediately and can be added any time.
    a unique catalogue number for each that would be assigned on upload.
    Unique catalog number could be CPAN ID plus filename. If it's assigned
    on upload, it is too probably late.
    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    I'd like to NOT have author's name and email in there because that is
    redundant information and tends to get out of date. We wouldn't want
    to ask people to re-upload just because their email address has
    changed, would we? Author's credentials are not in the OSD, right? But
    they are in the PPD. Hmmm. I'd say, it should go away. The CPAN ID is
    fine, it is associated with a record in a public database and the
    record can be edited by the person. PAUSE could refuse an upload if
    the ID in the OSD isn't the same as the person doing the upload or
    some such.

    --
    andreas
  • Graham Barr at Aug 2, 2000 at 9:18 am

    On Tue, Aug 01, 2000 at 11:07:47PM +0200, Andreas J. Koenig wrote:
    On Tue, 1 Aug 2000 14:50:19 -0500, elaine@chaos.wustl.edu (Elaine M. Ashton) said:
    Andreas J. Koenig [andreas.koenig@anima.de] quoth:
    *>
    *>I'm not arguing for changing the format but to optimize it for what we
    *>are doing. The most urgent points I would like to see addressed are:
    *>
    *>- List of and checksums for all files in the distribution,
    Could you elaborate on this a bit? What is the checksum good for, where
    would it be stored and could it be obsoleted by a cryptographic signature?
    My idea was to have the complete list of contained files, each with a
    checksum. This can be signed then. A signature that is produced this
    way can be included in the distribution file and doesn't need to be
    distributed separately. Distributing separately is considered annoying
    and errorprone.
    I had a thought about this. What is this actually giving us. It obviously
    gives some comfort if the dist is signed by it's author. But what is
    to stop some evil person you hacks some CPAN FTP site from just removing
    the signature when they corrupt a distribution. Maybe pause could create
    signatures for non-signed uploads.
    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    I'd like to NOT have author's name and email in there because that is
    redundant information and tends to get out of date.
    So does the README. It may be redundant due to the fact that it is in an authors
    directory on CPAN. But once the distribution leaves CPAN that knowledge is
    lost and having it in the OSD gives a KNOWN place to find such information.
    Author's credentials are not in the OSD, right? Right.
    But
    they are in the PPD. Hmmm. I'd say, it should go away. The CPAN ID is
    fine, it is associated with a record in a public database and the
    record can be edited by the person. PAUSE could refuse an upload if
    the ID in the OSD isn't the same as the person doing the upload or
    some such.
    Would you always want to force that. For example why would the perl distribution
    not be able to set the field to <perl5-porters@perl.org> ?

    Graham.
  • Andreas J. Koenig at Aug 2, 2000 at 3:06 pm

    On Wed, 2 Aug 2000 10:14:37 +0100, Graham Barr said:
    My idea was to have the complete list of contained files, each with a
    checksum. This can be signed then. A signature that is produced this
    way can be included in the distribution file and doesn't need to be
    distributed separately. Distributing separately is considered annoying
    and errorprone.
    I had a thought about this. What is this actually giving us. It obviously
    gives some comfort if the dist is signed by it's author. But what is
    to stop some evil person you hacks some CPAN FTP site from just removing
    the signature when they corrupt a distribution. Maybe pause could create
    signatures for non-signed uploads.
    I had the imagination that the author would store a policy on PAUSE
    for uploads into his directory, and that the user would store a
    per-author policy for handling downloaded files from CPAN.

    If the author would decide in favor of policy "strict", PAUSE would
    not accept uploads that are not signed by exactly that author. I do
    not envision other policies except "strict" and "not strict".

    If users would decide for the policy {"GBARR"=>"strict"}, they would
    not let their software install anything by GBARR that is not signed by
    GBARR. Users could have a default policy for all authors except those
    in the per-name policy list. Another policy besides strict would be
    "ask", I suppose. There may be more.

    A signature by PAUSE is an interesting idea. But it would tell the
    user something different than a signature by a person. While I imagine
    that a sig by GBARR would mean something like: "I have written or at
    least doublechecked the code in this package to be free from malicious
    intent. This is not a warranty." (careful considerations about wording
    pending). A signature of the PAUSE could only mean "These checksums
    were valid at the time of the upload."
    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    I'd like to NOT have author's name and email in there because that is
    redundant information and tends to get out of date.
    So does the README. It may be redundant due to the fact that it is in an authors
    directory on CPAN. But once the distribution leaves CPAN that knowledge is
    lost and having it in the OSD gives a KNOWN place to find such information.
    Author's credentials are not in the OSD, right? Right.
    But
    they are in the PPD. Hmmm. I'd say, it should go away. The CPAN ID is
    fine, it is associated with a record in a public database and the
    record can be edited by the person. PAUSE could refuse an upload if
    the ID in the OSD isn't the same as the person doing the upload or
    some such.
    Would you always want to force that. For example why would the perl distribution
    not be able to set the field to <perl5-porters@perl.org> ?
    Who has the private key of the perl5-porters? I believe, the signing
    must remain a strictly personal testimony. We should be prepared to
    let many people sign something, e.g. a release manager makes the
    release and asks the pumpking to also sign. But a group as such can
    only be presented by one signature for each member.

    --
    andreas
  • Jeremy Wadsack at Aug 2, 2000 at 3:24 pm

    "Andreas J. Koenig" wrote:

    I had the imagination that the author would store a policy on PAUSE
    for uploads into his directory, and that the user would store a
    per-author policy for handling downloaded files from CPAN.

    If the author would decide in favor of policy "strict", PAUSE would
    not accept uploads that are not signed by exactly that author. I do
    not envision other policies except "strict" and "not strict".

    If users would decide for the policy {"GBARR"=>"strict"}, they would
    not let their software install anything by GBARR that is not signed by
    GBARR. Users could have a default policy for all authors except those
    in the per-name policy list. Another policy besides strict would be
    "ask", I suppose. There may be more.
    This sounds as confusing as P3P! Why complicate CPAN? Initializing the CPAN module is
    already compicted enough for non-Perl users. Certainly some options can have defaults,
    but what kind of default do you choose for a security measure?


    A signature by PAUSE is an interesting idea. But it would tell the
    user something different than a signature by a person. While I imagine
    that a sig by GBARR would mean something like: "I have written or at
    least doublechecked the code in this package to be free from malicious
    intent. This is not a warranty." (careful considerations about wording
    pending). A signature of the PAUSE could only mean "These checksums
    were valid at the time of the upload."
    Again, my problem with requiring user signatures is that it complicates the module
    distribution process. Unless there's a really EASY way for people to acquire a
    signature and apply it to their modules, you're going to just increase the attrition in
    Perl developers.


    Jeremy Wadsack
    Wadsack-Allen Digital Group
  • Elaine -HFB- Ashton at Aug 2, 2000 at 4:03 pm
    Jeremy Wadsack [jwadsack@wadsack-allen.com] quoth:
    *>
    *>> A signature by PAUSE is an interesting idea. But it would tell the
    *>> user something different than a signature by a person. While I imagine
    *>> that a sig by GBARR would mean something like: "I have written or at
    *>> least doublechecked the code in this package to be free from malicious
    *>> intent. This is not a warranty." (careful considerations about wording
    *>> pending). A signature of the PAUSE could only mean "These checksums
    *>> were valid at the time of the upload."
    *>
    *>Again, my problem with requiring user signatures is that it complicates
    *>the module distribution process. Unless there's a really EASY way for
    *>people to acquire a signature and apply it to their modules, you're going
    *>to just increase the attrition in Perl developers.

    Hang on, don't get too excited just yet as these are just ideas being
    tossed around. However, the PGP signature is an idea I ran across on
    c.l.p.m. a few months back when someone was wondering what good the MD5
    checksums were and what, if anything, could be stronger. Now, the only
    person who is going to know the code intimately is going to be the
    developer of a particular module and CPAN certainly can't spend calendar
    years wading through code to be sure that modules haven't been tampered
    with at any point in time.

    It doesn't have to be a burden to the developer and I'm tired of hearing
    people say "CPAN sucks and doesn't have QA" out of one orifice and "Don't
    burden me out of the other". Compromises must be made here.

    So, I like the idea of it being optional, but I think there are ways to
    make it agreeable to the CPAN developers and make it an attractive option
    to sign their code cryptographically so as to reassure the user that the
    code is, at the very least, marginally secure. We could build some sort of
    PKI with minimal resources.

    I need more coffee, but these are simply ideas at this point, no need to
    get your panties in a bunch over letting your imagination go in the
    attempt to find something that really make CPAN a really useable space.

    btw - Randy Kobes, Ulrich and Paul Schinder might have some very useful
    input should someone care to invite them here and they are willing to join
    in.

    e.
  • Jeremy Wadsack at Aug 2, 2000 at 4:18 pm

    Elaine -HFB- Ashton wrote:

    Jeremy Wadsack [jwadsack@wadsack-allen.com] quoth:
    *>
    *>> A signature by PAUSE is an interesting idea. But it would tell the
    *>> user something different than a signature by a person. While I imagine
    *>> that a sig by GBARR would mean something like: "I have written or at
    *>> least doublechecked the code in this package to be free from malicious
    *>> intent. This is not a warranty." (careful considerations about wording
    *>> pending). A signature of the PAUSE could only mean "These checksums
    *>> were valid at the time of the upload."
    *>
    *>Again, my problem with requiring user signatures is that it complicates
    *>the module distribution process. Unless there's a really EASY way for
    *>people to acquire a signature and apply it to their modules, you're going
    *>to just increase the attrition in Perl developers.

    Hang on, don't get too excited just yet as these are just ideas being
    tossed around. ... I need more coffee, but these are simply ideas at this
    point, no need to get your panties in a bunch over letting your imagination
    go in the attempt to find something that really make CPAN a really useable
    space.
    Uh.. I didn't mean for that to appear a flame. Perhaps I'm not into the whole
    brainstorming idea, but I wanted to bring into light what I considered a
    potentially likely response to digital signatures.

    Perhaps, I should have been more politic and (more explicitely) suggested a
    solution along with my concerns. Specifically, I was thinking:

    We could build some sort of PKI with minimal resources.
    And some sort of tie-in to MakeMaker that automatically retrieves the signature
    or assignes one if none is already registered. In other-words, making the
    signing process vitually transparent to the developer. This would be cool and
    allow securing code.


    Jeremy Wadsack
    Wadsack-Allen Digital Group
  • Andreas J. Koenig at Aug 2, 2000 at 4:38 pm

    On Wed, 02 Aug 2000 08:19:29 -0700, Jeremy Wadsack said:
    This sounds as confusing as P3P! Why complicate CPAN? Initializing
    the CPAN module is already compicted enough for non-Perl users.
    Certainly some options can have defaults, but what kind of default
    do you choose for a security measure?
    The default is open house of course as is now. Security is a choice
    and what I describe here is just what I believe is needed to provide
    security for those who want it. I'd welcome soggestions how to make it
    easy to use. But befiore we can make it really easy we must have a
    working prototype.
    A signature by PAUSE is an interesting idea. But it would tell the
    user something different than a signature by a person. While I imagine
    that a sig by GBARR would mean something like: "I have written or at
    least doublechecked the code in this package to be free from malicious
    intent. This is not a warranty." (careful considerations about wording
    pending). A signature of the PAUSE could only mean "These checksums
    were valid at the time of the upload."
    Again, my problem with requiring user signatures is that it
    complicates the module distribution process. Unless there's a
    really EASY way for people to acquire a signature and apply it to
    their modules, you're going to just increase the attrition in Perl
    developers.
    It must be an option item for both producers and consumers, otherwise
    it will do what you say. Did I not make it clear enough that I want
    security as an optional feature? The OSD should help to implement the
    framework that allows security. Currently the options we have are all
    too complicated. Please correct me if I'm wrong.

    --
    andreas
  • Jeremy Wadsack at Aug 2, 2000 at 4:56 pm

    "Andreas J. Koenig" wrote:

    Did I not make it clear enough that I want security as an optional feature? The OSD should
    help to implement the framework that allows security. Currently the options we have are all
    too complicated. Please correct me if I'm wrong.
    I believe you did. Apparently I'm not following closely enough to make sensable comments.

    The day started with a tech-support request something like this:
    I can't get your product to work. Please help?
    What's wrong with it? What isn't working?
    It doesn't work. Help.

    So, perhaps it's my mood. I will now recede once again to the shadows of the CPAN-workers'
    circle and withold comments (here and elsewhere) for the balance of the day.

    Well, one more comment. Despite my devil's advocate responses, I am really impressed with
    everything you have discussed and think that you are on the way to something amazing (even more
    so that CPAN already is -- no other language, that I know of, has such a unified resource).
    Keep up the good work!

    Jeremy Wadsack
    Wadsack-Allen Digital Group
  • Elaine -HFB- Ashton at Aug 2, 2000 at 5:30 pm
    Andreas J. Koenig [andreas.koenig@anima.de] quoth:
    *>
    *>The default is open house of course as is now. Security is a choice
    *>and what I describe here is just what I believe is needed to provide
    *>security for those who want it. I'd welcome soggestions how to make it
    *>easy to use. But befiore we can make it really easy we must have a
    *>working prototype.

    Well, it will be security in a very loose sense of the term but it may be
    a worthwhile thing.

    PGP or MD5?
    Makemaker/PAUSE/manual author addition?

    What is it that the user and the author will get out of signed code?
    Will this create useless bloat or useful hurdles?

    I'm not particularly sold on any particular idea other than some change
    for CPAN will be a good thing, particularly useful information and
    features that make CPAN easy to navigate and easier to trust.

    *>It must be an option item for both producers and consumers, otherwise
    *>it will do what you say. Did I not make it clear enough that I want
    *>security as an optional feature? The OSD should help to implement the
    *>framework that allows security. Currently the options we have are all
    *>too complicated. Please correct me if I'm wrong.

    There are people who write complex modules so keep tossing out ideas and
    possibly the most obviously simple one will be a combination of them or
    something else entirely.

    I like the method of making something cool enough and easy/simple enough
    as to be compelling to both sides of the equation to use it. Optional,
    yes, but everything in life except for food, water and shelter is optional
    but the constructs of life make us think we need everything else.

    We're on the same side so I'd like to think we could offer ideas and
    opinions here with an open mind. I'll keep a tally of ideas and items and
    when we have a good list we can sift the good from the not so good and see
    what works from there.

    e.
  • Graham Barr at Aug 2, 2000 at 4:29 pm

    On Wed, Aug 02, 2000 at 05:06:17PM +0200, Andreas J. Koenig wrote:
    A signature by PAUSE is an interesting idea. But it would tell the
    user something different than a signature by a person. While I imagine
    that a sig by GBARR would mean something like: "I have written or at
    least doublechecked the code in this package to be free from malicious
    intent. This is not a warranty." (careful considerations about wording
    pending). A signature of the PAUSE could only mean "These checksums
    were valid at the time of the upload."
    Well at least the user knows that what they got is exactly what was uploaded.
    But
    they are in the PPD. Hmmm. I'd say, it should go away. The CPAN ID is
    fine, it is associated with a record in a public database and the
    record can be edited by the person. PAUSE could refuse an upload if
    the ID in the OSD isn't the same as the person doing the upload or
    some such.
    Would you always want to force that. For example why would the perl distribution
    not be able to set the field to <perl5-porters@perl.org> ?
    Who has the private key of the perl5-porters? I believe, the signing
    must remain a strictly personal testimony. We should be prepared to
    let many people sign something, e.g. a release manager makes the
    release and asks the pumpking to also sign. But a group as such can
    only be presented by one signature for each member.
    The AUTHOR field is not related to the signature. Actually I would always
    consider LArry as the author of perl, so I would expectLarry to appear
    as the AUTHOR in the OSD, unless he said he wanted someother email address in there.

    Graham.
  • Andreas J. Koenig at Aug 2, 2000 at 5:47 pm

    On Wed, 2 Aug 2000 17:25:03 +0100, Graham Barr said:
    But
    they are in the PPD. Hmmm. I'd say, it should go away. The CPAN ID is
    fine, it is associated with a record in a public database and the
    record can be edited by the person. PAUSE could refuse an upload if
    the ID in the OSD isn't the same as the person doing the upload or
    some such.
    Would you always want to force that. For example why would the perl distribution
    not be able to set the field to <perl5-porters@perl.org> ?
    Who has the private key of the perl5-porters? I believe, the signing
    must remain a strictly personal testimony. We should be prepared to
    let many people sign something, e.g. a release manager makes the
    release and asks the pumpking to also sign. But a group as such can
    only be presented by one signature for each member.
    The AUTHOR field is not related to the signature. Actually I would always
    consider LArry as the author of perl, so I would expectLarry to appear
    as the AUTHOR in the OSD, unless he said he wanted someother email address in there.
    Good point. There are many such cases on CPAN. PDL for example has
    often changing release manager. Archive::Tar has gone through several
    hands, When we realized that for the first time, we started to use the
    words "maintainer" and "contact" instead of "author". Only the
    directory "authors" remained with that name.

    For the purpose of making CPAN more maintainable, I see no need to
    have an AUTHOR field in the OSD.

    --
    andreas
  • Graham Barr at Aug 2, 2000 at 8:13 pm

    On Wed, Aug 02, 2000 at 07:47:09PM +0200, Andreas J. Koenig wrote:
    The AUTHOR field is not related to the signature. Actually I would always
    consider LArry as the author of perl, so I would expectLarry to appear
    as the AUTHOR in the OSD, unless he said he wanted someother email address in there.
    Good point. There are many such cases on CPAN. PDL for example has
    often changing release manager. Archive::Tar has gone through several
    hands, When we realized that for the first time, we started to use the
    words "maintainer" and "contact" instead of "author". Only the
    directory "authors" remained with that name.

    For the purpose of making CPAN more maintainable, I see no need to
    have an AUTHOR field in the OSD.
    Maybe AUTHOR is just the wrong name. Maybe it should be something like CONTACT,
    but there should be an entry for a name+email just like there
    is an entry for a homepage url.

    I am thinking more along the lines of when the distribution is taken out
    of the context of CPAN.

    Also one thing that may (or may not) be worth considering is using the
    OSD as a record of what has been installed on a system. The sys admin then
    has a database installed of what modules they have installed what versions,
    thier homepages, contact info etc...

    Graham.
  • Graham Barr at Aug 2, 2000 at 9:09 am

    On Tue, Aug 01, 2000 at 02:50:19PM -0500, Elaine -HFB- Ashton wrote:
    Andreas J. Koenig [andreas.koenig@anima.de] quoth:
    *>- a signature
    *>- a list of namespaces used within the files that are being installed
    *> by this distribution
    *>- a list of version numbers
    list of version numbers ? Do you mean the versions of all included modules ?
    I'd like to see a the dependancies and possibly a list of 'categories' and
    a unique catalogue number for each that would be assigned on upload.

    What else would people like to see besides author, email, name, version,
    url, signature, dependancies....???
    * keywords to help the search engines.
    * distribution description, both a short and a long description


    Graham.
  • Andreas J. Koenig at Aug 2, 2000 at 2:41 pm

    On Wed, 2 Aug 2000 10:04:53 +0100, Graham Barr said:
    list of version numbers ? Do you mean the versions of all included modules ?
    Yes. And version numbers of included scripts also come to mind.

    --
    andreas
  • Gurusamy Sarathy at Jul 31, 2000 at 7:37 am

    On 29 Jul 2000 10:19:36 +0200, Andreas J. Koenig wrote:
    On Thu, 27 Jul 2000 13:13:59 +0100, Graham Barr <gbarr@pobox.com> said:
    One thing that came up during the meeting was that there should be
    one OSD per dist which covers all implementatons. I was skeptical
    of this at the time, but now having thought a bit more I think it
    would work.
    I'd really like to keep the way CPAN is working now, just start using
    well specified metadata for it. The OSD probably promises too much. In
    practice it (well, its cousin in law PPD) only has proofed working for
    one architecture -- or are there any other known places it ever was
    used?
    It works on Solaris, Linux and Windows. (ActiveState maintains PPM
    repositories for all three platforms.)


    Sarathy
    gsar@ActiveState.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedJul 26, '00 at 5:35p
activeAug 2, '00 at 8:13p
posts31
users10
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase