[Slackbuilds-users] Arch User Repository compromise

[J. Milgram]

How about asking maintainers to submit separate gpg signature files when uploading packages, like the .asc sig files we now download from the repo. Introduces key trust issues but upside is that it should be simple to verify immediately on uploading.
 

 
(Not a fan of having yet one more password...)
 

 

 

 
 
 
 
 
>  
> On Jun 12, 2026 at 10:54, Willy Sudiarto Raharjo  <willysr at slackbuilds.org>  wrote:
>  
>  
>   >>  [...] unless we force all maintainers to
> >>  submit updates via github/gitlab, this kind of situation is easy to
> >>  reproduce, since you just need to know maintainer's email in order to
> >>  submit a new updates on behalf of the original maintainer.
> >
> >I'm not a fan of using those services, but if that's the price to pay, so be
> >it.
> >
> >I don't think using gitlab/github is the only way. For example:
> >
> >1. SB can send emails to every maintainer, letting them set up a password.
> >Later, when they use the submit form, they must fill this optional password
> >field. After the submission, the CI behind the scene, checks if the provided
> >pass matches the maintainer's pass...
> >
> >2. We can use Forgeo instance from AlienBOB. I'm pretty sure he'll help us
> >there despite his size limit. Or we can run our own instance. I'll be more
> >than happy to donate money in that direction.
> >
> >3. People can send patches in the form of signed emails (as less popular of an
> >option it might be, it still could ork).
> >
> >
> >>  [...] we do weekly updates, so everyone can review the
> >>  current week's progress in  https://slackbuilds.org/ready/  before it's
> >>  merged.
> >
> >Rarely anyone is going to check that. Security is best kept in check when it
> >is automatically enforced.
>
> We follow the KISS principle :)
> this is just my personal opinion though
> #1: we have to keep in mind of everyone's password, which i think people will
> forget to do for sure, especially if he's doing mass updates at once.
> #2 configuring it to work with SBo infrastructure might be a little bit
> complicated as the public updates MUST be done in the SBo machine itself due to
> the custom workflow that SBo adopted for years.
> #3 we allowed this during preparation for new repo, but it's a bit hassle to
> make a branch for each patches and push it to github/gitlab to test it against
> CI manually, where people can just send PR/MR directly and even some
> maintainers are given access to run the bot directly
>
>
> --
> Willy Sudiarto Raharjo
>    
>  
>  _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives -  https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ -  https://slackbuilds.org/faq/
>
>    
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260612/df4e30d3/attachment.htm>