People are losing permissions (during upload?)

[andk]

In November ETJ lost perms on PDL::LinearAlgebra::{Real,Trans,Special}. Six postings leading to resolution https://www.nntp.perl.org/group/perl.modules/2019/12/msg100697.html

[neilb]

This also happened to Hash::Merge.

At the start of July, the permissions were:

Hash::Merge,DMUEY,c
Hash::Merge,HERMES,c
Hash::Merge,MNEYLON,c
Hash::Merge,REHSACK,f

Then HERMES did two releases, 0.301 and 0.302, and one of those releases seems to have resulted in all permissions being deleted. On the evening of 2020-07-30 (UTC), I checked and confirmed that there were no permissions on Hash::Merge at all.

I've added them back.

[oalders]

I’m wondering if this happened to me with WWW-YouTube-Download. I tried to upload a new release last month and my perms were gone:

User: OALDERS (Olaf Alders) Distribution file: WWW-YouTube-Download-0.63.tar.gz Number of files: 44 *.pm files: 1 README: WWW-YouTube-Download-0.63/README.md META-File: WWW-YouTube-Download-0.63/META.json META-Parser: Parse::CPAN::Meta 1.4414 META-driven index: no Timestamp of file: Tue Jun 23 21:14:59 2020 UTC Time of this run: Tue Jun 23 21:36:41 2020 UTC

ERROR: Database error occurred during index update

This distribution name will only be indexed when uploaded by users with permission for the package WWW::YouTube::Download. Either someone else has ownership over that package name, or this is a brand new distribution and that package name was neither listed in the 'provides' field in the META file nor found inside the distribution's modules. Therefore, no modules will be indexed.

Further details on the indexing attempt follow.

The following packages (grouped by status) have been found in the distro:

Status: Permission missing

module : WWW::YouTube::Download
version: 0.63
in file: WWW-YouTube-Download-0.63/lib/WWW/YouTube/Download.pm
status : Not indexed because permission missing. Current registered
        primary maintainer is XAICRON. Hint: you can always find
        the legitimate maintainer(s) on PAUSE under "View
        Permissions".

[neilb]

@oalders as an additional data point, did you have co-maint on the relent packages, or did you have first-come on some?

[oalders]

@neilb I had co-maint. I've contacted @xaicron about this, but I haven't heard back yet. If I was intentionally removed as co-maint, I was never made aware of it. There's only one package in this dist: WWW::YouTube::Download. I've been the only releaser for 5 years, so my first thought was that something may have gone wrong with the index.

[oalders]

I'm sorted at this point as I've kindly been re-added to the index now. 😃

[neilb]

It looks like this might also have happened when BINGOS released Module-CoreList on 2020-09-20.

On the 15th September, the permissions on the lead module were:

Module::CoreList,BINGOS,c
Module::CoreList,KANE,c
Module::CoreList,P5P,f
Module::CoreList,RGARCIA,c
Module::CoreList,RJBS,c

After Chris's release, the permissions are now (on 2020-09-21):

Module::CoreList,BINGOS,c
Module::CoreList,KANE,c
Module::CoreList,RGARCIA,c
Module::CoreList,RJBS,c

I only spotted this because I have a script which reports distributions with inconsistent first-comes, and Module-CoreList turned up in the list this morning.

[neilb]

I think I've worked out the problem. First, here's what I think is happening

• In the past, if you had first-come (an entry in the table primeur), then you also had co-maint (an entry in table perms).
• When 06perms.txt is generated, it just lists your highest permission, so if you have both first-come and co-maint, the file only lists your first-come
• But I suspect that the relatively recent changes for dist-level transfers of permissions don't given you the co-maint if you're gaining first-come
• When a release is done, if the indexer runs, then if a user has first-come but doesn't have co-maint, then they lose the first-come.

I think this is down to canonicalize_module_casing() in PAUSE::PermsManager. Here's my theory:

If this is all correct, then the query could be replaced with something like:

SELECT
    primeur.user,
    1 AS is_primary
    FROM primeur
    WHERE lower(primeur.package) = 'module::corelist'
UNION
SELECT
    perms.user,
    0 AS is_primary
    FROM perms
    WHERE lower(perms.package) = 'module::corelist'
        AND perms.user NOT IN (SELECT user FROM primeur WHERE lower(package) = 'module::corelist')
;

But exactly how that query is written depends on whether a user can ever have more than one entry in perms or primeur for a given package? With the case insensitivity changes, I hope not, but ...

[neilb]

Hmm, @oalders is pretty sure that he had co-maint on WWW::YouTube::Download, and that was the indexing permission that was lost when he did a release of WWW-YouTube-Download.

I'll work through the code again and see if I can work out an explanation for co-maints being lost.

[neilb]

I think there are two separate bugs here. Another case happened this week, where ETJ was given perms on GraphViz2, but after ETJ's first release, the first-come on GraphViz2 was lost. I need to look into the specifics of that, and also fix it. Noting it here for the record.

[neilb]

I have written a PAUSE test to confirm the loss of first-come, in the following situation:

1. A distribution contains a package Foobar
2. Author Bill used to have first-come, but it was transferred to Fred (who didn't already have co-maint), using the "transfer primary on dist" function
3. Bill ends up with co-maint, and Fred has first-come, but only has an entry in table primeur, not in perms.
4. If the co-maint (Bill) does the next release, then Fred's first-come (entry in primeur only) gets lost.
5. If instead, Fred did the next release, then the indexer will end giving up him the entry in perms that he didn't get on transfer. And if Bill follows up Fred's release with one of his own, this time Fred's first-come won't be lost.

[ap]

• Author Bill used to have first-come, but it was transferred […]
• Bill ends up with co-maint, and Fred has first-come

OK. But then…

• […] Bill's first-come gets lost.
• […] this time Bill's first-come won't be lost.

I’m confused… I thought Bill didn’t have first-come any more? My next thought was that you must have just mixed up Fred and Bill in the last two items – but just switching them doesn’t make anything make sense either. So I think that all of the references to Fred and Bill are correct except those last two quoted ones, where instead you meant Fred’s first-come. Is that correct?

[neilb]

Oops, thanks Artistotle, I was tired and wanted to write it up before hitting the sack. I've corrected the one place where it should have been "Fred" and not "Bill".

[ap]

Based on your correction it seems to me the very last mention of Bill should also refer to Fred instead.

[rjbs]

This was deployed.

By the way, @neilb , awesome code markup image.