[Slackbuilds-users] Alan Aversa (aka Caterino Tommaso, T.O.P.)

B. Watson urchlay at slackware.uk
Tue Aug 25 07:20:41 UTC 2026



On Tue, 25 Aug 2026, David O'Shaughnessy wrote:

> On Mon, 24 Aug 2026, at 3:59 PM, B. Watson wrote:
>> - Submitting updates for other peoples' builds without permission.
>
> Given the nature of the form at https://slackbuilds.org/submit/ (no authentication or submission email verification)

Well, there's no authentication, but there is submission email
verification: the form verifies that the email address exists, and
can be reached via SMTP (does a "RCPT TO"). You're right in that it
doesn't verify that the user's email address matches the .info file's
maintainer email: there's no rule that says you have to use the same
email address for both. This is a feature...

Example: My primary email address is on a domain (slackware.uk) that
does greylisting. On the rare occasions I use the submit form, I use
a different email address (which doesn't do greylisting), to avoid
the greylist delay of 5 minutes. This means the email in my .info file
doesn't match the email I entered into the submission form. And I know
I'm not the only one who does this regularly.

> can't the practice of submitting updates without permission still continue though?

Yes, it can. Which is why, when it happens, we contact the person who
did it, explain the situation, and ask them nicely to stop.

When it's happened in the past, the updaters have responded positively
for the most part. "Sorry, I didn't know it wasn't allowed", etc.

The only reason Aversa/Caterino is getting singled out is that he
hasn't responded to our attempts to contact him, for over a month now
(and actually, it goes back further than that, we just didn't start
documenting it until a month ago).

In the past few days, I've given some thought to the idea of having
all maintainers create user accounts, and log in before they're
allowed to submit a build... and prevent anyone from updating anyone
else's build unless they have permission (the one giving permission
would log in and have some kind of UI for giving permission).

Having maintainer user accounts and requiring browser logins would be
a pain in everyone's ass. Maintainers would have extra hoops to jump
through, and someone from the SBo admin team (probably me) would have
to write all the code (in PHP, SQL, and maybe JavaScript).

Plus, this still wouldn't stop unauthorized updates: users can update
builds via PR/MR on github, gitlab, and codeberg. I don't think we can
do anything there beyond what we're already doing: look at the user
who sent the update, see if it's the same as the maintainer.


More information about the SlackBuilds-users mailing list