<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">Yes, one of my Slackbuilds was apparently updated recently (by a bot or something?) and it was said to be committed by my GitHub username even though I had nothing to do with it. I don't have a problem with automatic updates in some situations if this makes maintenance easier for Willy and team, but I am not comfortable with being impersonated. It shouldn't have my username on it if someone else did it.<div dir="auto"><br></div><div dir="auto">Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On May 15, 2026 6:35 PM, Lumin Etherlight via SlackBuilds-users <slackbuilds-users@slackbuilds.org> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Arnaud via SlackBuilds-users
<br>
<slackbuilds-users@slackbuilds.org> writes:
<br>
<br>
> I am thinking about what could be done to
<br>
> our repository, changing a URL there under the
<br>
> pretense that its more stable, but is pointing to
<br>
> a modified version with security breaches. And
<br>
> all we'll see is that the official maintainer
<br>
> proposed the change and it was approved.
<br>
>
<br>
> Maybe there could be a group effort toward a
<br>
> few modernizations, a bit more security, a better
<br>
> submission process ?
<br>
<br>
I agree. If anyone can publish an update in
<br>
my name, which may include "supply-chain" attacks,
<br>
against other Slackware users, then I'd be really
<br>
weary of having my name on SlackBuilds, lest I get
<br>
falsely accused of doing the attacks myself.
<br>
<br>
Cryptographic signatures by the private keys
<br>
of the maintainer is the usual mitigation in other
<br>
projects as far as I know. If a developer adopts
<br>
a package, then their key is marked as the only
<br>
one allowed to push updates to said package. If
<br>
an admin needs to modify the uploaded update, then
<br>
the administrator's signature has to be on that
<br>
update instead.
<br>
<br>
I wonder if current SlackBuild.org policy
<br>
allows individual maintainers to sign their own
<br>
updates, by optionally including a signature file
<br>
in their upload, which gets published to the end
<br>
users just like any file in the SlackBuild. Users
<br>
who want to be extra cautious can then validate it
<br>
to make sure nothing weird is happening. Would my
<br>
updates be rejected if I do so?
<br>
<br>
At minimum, we need email confirmation sent
<br>
to the maintainers' address when they make uploads
<br>
so that their identity is slightly confirmed.
<br>
<br>
Simpler solutions are welcome,
<br>
if anyone has any :-)
<br>
<br>
<br>
Best Regard,
<br>
Lumin Etherlight
<br>
_______________________________________________
<br>
SlackBuilds-users mailing list
<br>
SlackBuilds-users@slackbuilds.org
<br>
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
<br>
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
<br>
FAQ - https://slackbuilds.org/faq/
<br>
<br>
</p>
</blockquote></div><br></div>