[Slackbuilds-users] [hplip-plugin] updated without my say-so, by someone who used my name and email.

[Andrew Clemons]

On 2026-05-16 01:35:40 +0300, slackbuilds-users at slackbuilds.org wrote:
> Arnaud via SlackBuilds-users
> <slackbuilds-users at slackbuilds.org> writes:
> 
> >       I am  thinking about  what could be  done to
> > our  repository, changing  a URL  there under  the
> > pretense that its more  stable, but is pointing to
> > a  modified version  with security  breaches.  And
> > all  we'll see  is  that  the official  maintainer
> > proposed the change and it was approved.
> >
> >       Maybe there could be a group effort toward a
> > few modernizations, a bit  more security, a better
> > submission process ?
> 
>         I agree.  If anyone can publish an update in
>   my name, which may include "supply-chain" attacks,
>   against other Slackware users,  then I'd be really
>   weary of having my name on SlackBuilds, lest I get
>   falsely accused of doing the attacks myself.
> 
>         Cryptographic signatures by the private keys
>   of the maintainer is the usual mitigation in other
>   projects as far as I  know.  If a developer adopts
>   a package,  then their key  is marked as  the only
>   one allowed  to push updates to  said package.  If
>   an admin needs to modify the uploaded update, then
>   the administrator's  signature has  to be  on that
>   update instead.
> 
>         I  wonder if  current SlackBuild.org  policy
>   allows  individual maintainers  to sign  their own
>   updates, by optionally  including a signature file
>   in their  upload, which gets published  to the end
>   users just like any file in the SlackBuild.  Users
>   who want to be extra cautious can then validate it
>   to make sure nothing weird is happening.  Would my
>   updates be rejected if I do so?
> 
>         At minimum, we  need email confirmation sent
>   to the maintainers' address when they make uploads
>   so that their identity is slightly confirmed.
> 
>   Simpler solutions are welcome,
>     if anyone has any :-)

Yes just to clarify how this is supposed to work at the moment - no
suggestions for improvement right now.

For maintainers who regularly submit updates through gitlab or github,
the admins know your handles so we _should_ realise when someone else
opens an MR or PR for your builds.

For submissions through the web form, the email address entered in the
form should receive an email and the admins should too. Currently this
is not working - Willy has posted about this multiple times, but for
whatever reason the people who have access have not been able to fix
it.

So the admins have the uploaded tarball and see the diff but we don't
see the email from the submission form. We can see the details in the DB
- Willy can correct me here if I am wrong, but the `sbodb` output
contains just the details in the db from the info file (afaik). So
when we create the diff, we can only make a commit based on the info
file attributing it to the address and name there.

This is the problem and the missing link of trust.

For people who regularly submit MRs and PRs, if we get a file upload, it
is unusual so Willy for example asked about in this case here:

https://github.com/SlackBuildsOrg/slackbuilds/pull/15365#issuecomment-4317247780

As Willy mentioned at the start of this thread, it was a mistake not to
wait for the answer here. There was nothing concerning in the update -
still pointing to upstream etc, just unusual that it came through the
submission form.

As far supply-chain issues mentioned, the admins are humans so we could
make mistakes, but if someone submits an update through the form or even
an MR/PR for a build and DOWNLOAD no longer points to upstream, a
version is rolled back or the script is doing things it should not, this
is a major flag for us to follow up on.

But agreed, we do need the emails from the submissions fixed - both for
maintainers submitting updates and for the admins cross referencing the
details during approval.

For maintainers who have access to our git, Willy does final review of
those branches when he merges them into his branch for publishing
during the weekly update.

Other than that approval, we do all our reviews and approvals in the
open. You can see them

here: https://gitlab.com/SlackBuilds.org/slackbuilds/-/merge_requests
and here: https://github.com/SlackBuildsOrg/slackbuilds/pulls

including the ones uploaded through the form:

e.g: https://github.com/SlackBuildsOrg/slackbuilds/pull/15687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260516/de79bad9/attachment.asc>