Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: OpenSnitch (Read 3653 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: OpenSnitch

Reply #15 –
placing system scripts in AUR is a bad idea... not only for security...

Re: OpenSnitch

Reply #16 –
I think many AUR helpers might only look in the original AUR and any repos configured in pacman.conf which would make it more difficult to have a new AUR, putting things in an Artix repo would be easier from that perspective than in an alternative AUR.
In Pakku at least it seems hardcoded in with no currently existing mechanism for configuration:
const
  aurUrl* = "https://aur.archlinux.org/"

Re: OpenSnitch

Reply #18 –
security, than check the PKGBUILD and files provided to make the package, and also whole package after it was created.
 

Re: OpenSnitch

Reply #20 –
In this case opensnitch itself is in the AUR, so it's more about whether it's better to place init scripts for AUR packages in the AUR or in the repos. If there were init scripts for every AUR package that needed one for every init available it might make a lot of extra AUR packages, especially if different Arch based distros had different versions as well. But if there were only a few it wouldn't make a lot of difference either way. Or perhaps they could be bundled in an <initname>-aur-init-script package, hosted somewhere you could make a PR to add new ones, a tiny bit wasteful on drive space but nothing like firmware etc. If it installed them to some dir then you could probably symlink them to /etc/init.d or equivalent to save cluttering up your initscript dir and they would still get updates.
Another approach is a split package, suggested here for this problem:
https://bbs.archlinux.org/viewtopic.php?id=250693

Re: OpenSnitch

Reply #22 –
Perhaps make the AUR package itself a split package. That would keep things together in a logical way yet not require extra PKGBUILD's that are possibly longer than the script they install. Some packages in the AUR already contain scripts in the source code which the PKGBUILD ignores, but it could be adapted to make those into sub-packages that could be installed independently. (Although the AUR Opensnitch PKGBUILD maintainer seems unwilling to support other inits.)

Re: OpenSnitch

Reply #23 –
Quote from: ####### – on
Perhaps make the AUR package itself a split package. That would keep things together in a logical way yet not require extra PKGBUILD's that are possibly longer than the script they install. Some packages in the AUR already contain scripts in the source code which the PKGBUILD ignores, but it could be adapted to make those into sub-packages that could be installed independently.


I totally agree! At Artix we do it always that way, so we should keep it that way. One PKGBUILD called "opensnitch" and three PKGBUILDs called "opensnitch-openrc", "opensnitch-runit" and "opensnitch-s6" for the init scripts.
Code: [Select]
ARTIX Dinit + SDDM + Enlightenment

Re: OpenSnitch

Reply #24 –
That's not how a split package works though, you can have one PKGBUILD that makes more than one package, and only the ones you specified with <aurhelper> -S will get installed. Some AUR packages already do this, e.g.:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nim-git
If you run <aurhelper> -S nim-git then nimble-git, nimsuggest-git, nimpretty-git get built but are simply deleted afterwards.
But say <aurhelper> -Ss nimble-git will still show it, as though they were individual packages.
So the opensnitch pkgbuild could have init scripts in individual packages for any init, the script itself would be located in either the AUR or the upstream source repo, but none of them would be installed unless the user wanted them. As the scripts don't need to be compiled and are just a few short files it wouldn't slow the build process. And they would be kept (and updated if required) alongside the package they refer to.

Re: OpenSnitch

Reply #25 –
Hmm, I see two problems:
1.) Wouldn't this be very annoying for users of other distributions, who don't even know, what an init system is?
2.) In case the maintainer of the PKGBUILD is not from Artix, we won't be able to do that.

Wouldn't it be easier to add a separate PKGBUILD named opensnitch-s6-artix?
Code: [Select]
ARTIX Dinit + SDDM + Enlightenment

Re: OpenSnitch

Reply #26 –
Quote from: xanadu – on
Hmm, I see two problems:
1.) Wouldn't this be very annoying for users of other distributions, who don't even know, what an init system is?
2.) In case the maintainer of the PKGBUILD is not from Artix, we won't be able to do that.

Wouldn't it be easier to add a separate PKGBUILD named opensnitch-s6-artix?

1) opensnitch-s6 is fine as a PKGBUILD name on AUR
2) why so?

Re: OpenSnitch

Reply #27 –
1) No, why would it make any difference if you didn't install the extra initscript package? It wouldn't be in the original package. We install non-functional systemd service files from AUR packages. Many source bundles contain init scripts for a variety of inits, they are ignored by the build process, yet could be made available.
2) In case they are unhelpful you can't do that. I've had people from all manner of unexpected places help with Artix related issues, including those who work on projects alongside Lennart Poettering, when I asked nicely. But then you could try offering a patch to the PKGBUILD to make it easy for them (if you could figure one out of course  ;D ) and if they don't accept, at least you can take them off your Xmas card list and save a stamp.

3) From my link to the Arch forum discussion:
Alad Wiki Admin/IRC Op/TU (who you may also frequently see in GitHub issue discussions, and I consider to  be a reliable spokesperson for Arch Linux in general)
"Please don't create 20 PKGBUILDs for 20 services. If you insist on using 1 package per service, use a split package."

That's what Arch themselves recommend. If you want 1 package per service then put it in an Artix repo, which would also work. Probably that's the easiest but it would require a change in Artix policy regarding scripts for AUR packages. Or we could create the Artix User Repository and rewrite the aurhelpers to accomodate it, although there are lots in many different languages so probably only some would get done and it could take a while.

Re: OpenSnitch

Reply #28 –
1) Do they build the packages from our AUR PKGBUILDS, put them in their repos as packages, and so they have problems with that?

2) Also, that thread on Arch forum mentions "this thread is about systemd and openrc coexisting on an archlinux installation WITH the base meta-package installed", so is completely irrelevant to building one service for User's usage imho (AUR is for users, iirc)

Re: OpenSnitch

Reply #29 –
In the first post in this thread there's a suggested S6 init script from the opensnitch developer, so that could go somewhere when a location is decided on.
  There are 2 opensnitch variants in the AUR, there's gustav-iniguez-goya and "opensnitch" which is a fork from evilsocket and "opensnitch-git" which has been in the AUR for longer. And there's another GitHub issue about this on evilsocket opensnitch-git:
https://github.com/evilsocket/opensnitch/issues/300

The only example of openrc scripts in a split package I found in the AUR is this (although I didn't check everything):
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=openrc-accessible
so it doesn't seem very common.