Re: TAPx::Parser 0.10 (now with stream support)

[Ovid]

- Original Message 
From: jerry gay <[EMAIL PROTECTED]>

># the following items are hashes because they are sparse arrays

> these don't seem to be hashes, as the comment suggests.

Ah, thanks.  That was from an older version.  I'll clear that out.

Cheers,
Ovid

Re: Kwalitee metric: Community support channels

[Shlomi Fish]

Hi Salve!

See below for my comments.

On Monday 24 July 2006 16:23, Salve J Nilsen wrote:
> Shlomi Fish wrote:
> > On Wednesday 19 July 2006 17:08, Salve J Nilsen wrote:
> >> Just a wild thought...
> >>
> >> Would it be useful to check for references to community support channels
> >> like mailing lists, IRC channels, public bug trackers and official web
> >> pages?
> >
> > Interesting idea. One thing I should probably note is that ESR has this
> > recommendation in "The Cathedral and the Bazaar":
>
> [http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.htm
>l]
>
> [Shlomi's experiences using different community channels]
>
> > What did I want to say? Yes, often the scope or maturity of the module
> > does not justify a special "community" support channels. So I'm not sure
> > whether penalising CPAN distros for not having this information is a good
> > idea. But I'll have to think about it some more.
>
> I'd rather look at these metrics as a way of encouraging developers to
> think about issues around community sustainment. That way, we can use "the
> game" as a tool for software improvement in addition to improving the
> codebase. 

Sure, that's probably good.

> Which specific types of channels one should get points for may 
> warrant discussion, but if our goal is the improvement of the software, we
> should at least encourage a mininmum number of ways to reach the users and
> developers of a software project.
>
> I would suggest giving a point for explicitly (and in a consistently
> machine-readable manner) stating the project's...
>
>   * primary public bugtracker (frontpage URL) in use by it's users and
> developers 

Well, we have rt.cpan.org for free. I believe module-starter and friends can 
put it in the YAML by default, while allowing you to override with something 
else (in case you have your own different bug tracker, as is the case for 
Catalyst with their Trac.).

+1.

> * main public mailing list (subscription URL) in use by it's 
> users and developers 

Well sometimes people segment between the mailing list for developers and 
mailing list for users of the software. I was involved with the Subversion 
development for a while, and they had one common mailing list. Then they 
decided to separate it into [EMAIL PROTECTED] and 
[EMAIL PROTECTED]

I should also note that there are other types of mailing lists:

1. Mailing list for Version Control Commits.

2. Wine-style Licence/flames mailing list. (Just kidding).

3. Mailing list for individual components (Mozilla style madness, where I can 
never determine where to post something).

4. Etc.

> * publically searchable archive of the mailing list 
> (search page URL) 

Well, Google as well as mail-archive.com, yahoogroups, googlegroups etc. give 
you an archive and a search for free. The archive should be publicly 
accessible, and have some search functionality. I set up a htdig search for 
the entire Perl Mongers domain, and it was a pretty straightforward 
experience.

> * publically readable code repository (e.g. to a CVSWeb 
> or SVN::Web frontpage URL)

H... would a standard Subversion HTTP/S tree be enough? 

>
> "Instant" communication channels like IRC and IM can of course be useful,
> but since the chat logs usually aren't stored and indexed publically, their
> lon term usefulness for the community are somewhat limited.

True, but I solved many problems using IRC or at least got a lot of help.

>
> One could of course say distros that don't state ANY contact information or
> community support channels could be "penalized", but I'd guess these
> developers probably don't care enough about their software or "the game" to
> feel much penalty from losing those points.

Yes.

>
> The rest of us ("the CPAN/Perl community") can still get all the good
> stuff, in addition to some hints on which projects one shouldn't expect any
> improvements or support. :)
>

Yes.

I daresay that sometimes a simple forward or developer email address is enough 
as a contact address. Recently I encountered some people in Israel 
(relatively new to the Internet scene) who seem to dislike mailing lists and 
prefer web forums and other mediums. Some of them even complained that some 
relatively low volume mailing lists were high volume, while in fact they were 
less than p5p and perl6-language, and much less than BugTraq or the Linux 
Kernel Mailing List. 

There is some software for multiplexing between a web forum, a newsgroup, a 
mailing list and an RSS feed, which could be useful. But we need to consider 
whether we also want a forum (a la Gabor's http://www.cpanforum.com/ ) as 
well. I wonder if there's anyway I can become automatically subscribed to all 
the distributions I've ever maintained on cpanforum.com? That would be cool. 
Gabor, can you shed some light on this issue?

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http:

Re: Module Signatures

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-07-19 18:40]:
> My biggest criticism of every attempt I've seen at adding more
> security is that it reduces utility. And since we've NEVER
> (yet) had a security violation that I'm aware of, the net
> result is we just sacrifice utility for potential security
> gain.

That line of reasoning really troubles me: it implies that it’s
not worthwhile to protect against a plausible danger before real
damage has happened. In fact, if the measures are implemented
well, then the security gain from them will always remain
“potential”.

I’ll assume you didn’t actually mean it the way it came out; that
you were actually complaining about the tools. I agree that
Module::Signature falls far short of doing an adequate job; no
argument from me about that. But I think so not because it
decreases utility but because it doesn’t actually increase
security. When it decreases utility, it’s just because it fails
to work, not because in exchange for security.

If I could trade some utility for an actual increase in security,
I would.

Regards,
-- 
Aristotle Pagaltzis // 

Re: [Module::Build] Yikes! Module::Build 0.2804 produces META.yml with version objects

[Ken Williams]

On Jul 21, 2006, at 12:58 AM, Adam Kennedy wrote:


It's at this point I make very quiet noises about YAML::Tiny, and  
how it only supports ordinary data, so things like objects and  
circulars and other crazy things can't happen.


It's not "done" yet, but the basics all should work.

You might want to at least investigate it.


Thanks for the tip.  If we used it somehow, it would probably be to  
completely switch from YAML to YAML::Tiny.  I can't see YAML::Tiny as  
a fallback for YAML or something, that would get too complicated.


Might be another good candidate for auto-bundling once we get that  
mechanism worked out.


 -Ken

Re: Module Signatures

[Andreas J. Koenig]

> On Wed, 19 Jul 2006 18:09:08 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> 
> said:

 >> Maybe we need a perlish kind of building it. It's not perlish
 >> to show each other a passport and make sure that the image
 >> there matches the face.

  > hmm, I don’t know how else you’d do it; at least for high
  > confidence, you really have to be absolutely sure that you’re
  > signing the key of the person who is who they’re claiming to be,
  > and there isn’t much opportunity to be completely certain in
  > online interactions.

  > 1. If you ask CPAN contributors to supply their PK *at signup
  >time* (but no later!), you can be certain that the key belongs
  >to the person who signed up – whoever that is. (Keys uploaded
  >later do not confer the same trust, because that key might
  >belong to the person who signed up, or it might belong to an
  >impostor who stole their credentials – you can’t know.)

  >These could be signed with an extra CPAN key that confers more
  >trust.

  > 2. The best opportunity for strong trust is probably the fact
  >that a lot of the really active Perl hackers run into each
  >other face-to-face quite a bit; e.g. the London.pm’ers should
  >have absolutely no trouble exchanging keys face-to-face, but
  >the same is true of many Perlmongers groups. Likewise, many of
  >the core contributors of Perl attend the pertinent conferences
  >(YAPC, OSCON et al).

  >And of course the meaning of “web of trust” is that once
  >direct trust relationships have been established in local
  >groups where they are easily feasible, then every time someone
  >travels around or goes to a confidence and exchanges keys, you
  >get “six degrees of separation” style trust chains.

  >If we decided to make a big awareness push, we’d probably get
  >the prolific CPAN contributors covered well very quickly, and
  >then it’s a matter of continual evangelism to keep the web
  >expanding.

  > It is easy to implement #1 immediatly, but coverage will take a
  > very long time to go up with that method because it will only
  > apply to new authors.

Besides, private digital keys can expire or be revoked, both are
important parts of the life cycle that CPAN must pay attention to. I
would hate to tell people that they need a new CPAN account when their
private key expires or is revoked or that everybody needs a new CPAN
account because they didn't supply a digital key at signup.

Then there are pseudonyms like TELS or ERYQ or ABIGAIL. While they do
have a civic name, not many know it or care about it and so doesn't
CPAN either.

Then there is my favorite security builder: security by visibility. By
sending emails to authors for every important transaction, we give
them the chance to shout when suspicious things happen and make it
harder for intruders to impersonate somebody else.

Another helping fact might be that when you use a digital signature
often in public conversation or for your uploads, you leave a trace, a
fingerprint of your personality associated with the signature. It's
hard for me to imagine how this effect can be harvested by programming
interfaces, but see, I read your words in this thread and others and
that's how my trust in your name emerges. Were your postings signed, I
would be ready to sign your signature after a while of ongoing
conversation *without* seeing your passport.

  > In contrast, coverage should expand pretty quickly with #2, but
  > it will take a lot of community cooperation and lots of
  > evangelism to implement.

When we come up with a process that works similarly as #2 but only for
the trust we have into an email address, then we could get even better
and faster spread.

-- 
andreas

Re: Module Signatures

[Andreas J. Koenig]

> On Wed, 26 Jul 2006 04:08:05 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> 
> said:

  > I’ll assume you didn’t actually mean it the way it came out; that
  > you were actually complaining about the tools. I agree that
  > Module::Signature falls far short of doing an adequate job; no
  > argument from me about that. But I think so not because it
  > decreases utility but because it doesn’t actually increase
  > security. When it decreases utility, it’s just because it fails
  > to work, not because in exchange for security.

  > If I could trade some utility for an actual increase in security,
  > I would.

I'll assume you didn’t actually mean it the way it came out;) that you
were actually complaining that M:S falls short because our security
model needs *further* action not because M:S has deficiencies. If M:S
has deficiencies, maybe we should address them now.

-- 
andreas

Re: Module Signatures

[Andreas J. Koenig]

> On Thu, 20 Jul 2006 02:35:02 +1000, Adam Kennedy <[EMAIL PROTECTED]> said:

  > On the other hand, give me an easy to use, works _everywhere_, never
  > fails falsely positive or negative, never crashes, low-dependency
  > security enhancement to CPAN clients that I never have to think about,
  > then I'm in and I'll do anything you want.

Security is not a "never have to think about". We can inprove the
tools and make them work under battle conditions, but that's only one
dimension.

The other dimension is about improving security even with tools that
fail on Windows. We can and should do that. If we improve security
only for a small subset of users, we improve the overall security of
CPAN because the small subset can pull the alarm bell faster.

-- 
andreas

Re: Module Signatures

[Adam Kennedy]

Andreas J. Koenig wrote:

On Thu, 20 Jul 2006 02:35:02 +1000, Adam Kennedy <[EMAIL PROTECTED]> said:


  > On the other hand, give me an easy to use, works _everywhere_, never
  > fails falsely positive or negative, never crashes, low-dependency
  > security enhancement to CPAN clients that I never have to think about,
  > then I'm in and I'll do anything you want.

Security is not a "never have to think about". We can inprove the
tools and make them work under battle conditions, but that's only one
dimension.

The other dimension is about improving security even with tools that
fail on Windows. We can and should do that. If we improve security
only for a small subset of users, we improve the overall security of
CPAN because the small subset can pull the alarm bell faster.



I do agree, but if you are going to do that we should know NOT to tell 
people on failing platforms to do something we know is going to fail.


So if we know it doesn't work on Windows (for example) we shouldn't be 
telling them to install Module::Signature, because it just leads them 
down the wrong (painful) path.


Adam K

Re: Module Signatures

[Andreas J. Koenig]

> On Wed, 26 Jul 2006 12:10:07 +0800, Adam Kennedy <[EMAIL PROTECTED]> said:

  > I do agree, but if you are going to do that we should know NOT to tell
  > people on failing platforms to do something we know is going to fail.

  > So if we know it doesn't work on Windows (for example) we shouldn't be
  > telling them to install Module::Signature, because it just leads them
  > down the wrong (painful) path.

Right. CPAN 1.87_54 is uploaded and there you can turn on and off
signature checking more conveniently than in 1.87.

I'll make a 1.88 release RSN.

-- 
andreas