mmhh, tar.bz2 archive do not seem to be allowed on the list. I've attached all raw files. On Thu, Jul 22, 2021 at 02:15:53PM +0200, pcb-rnd--- via aur-general wrote:

Hi list,

I would like to have some feedback for my first PKGBUILD files for packages. the existing pcb-rnd-svn AUR package is currently broken because the project requires a need dependency: librnd3. thus I decided to create all packages needed/related by it, and fix its optional dependencies. I was able to create all packages on a fresh arch, and checked them against namcap. please let me know if the PKGBUILD are OK so I can submit them.

thanks, cuvoodoo

Hi, the attachments are good now.

# Maintainer: CuVoodoo pkgname=camv-rnd pkgver=1.0.0 pkgrel=1 pkgdesc="free/open source, small, flexible viewer for PCB-related CAM file formats" url="http://www.repo.hu/projects/camv-rnd/" arch=('i686' 'x86_64') license=('GPL2') depends=('librnd3' 'freetype2') provides=('camv-rnd') source=("http://www.repo.hu/projects/$pkgname/releases/$pkgname-$pkgver.tar.gz") sha256sums=('edf86c4d7d94364abc2b20bbfb3a78501a899f0b324ce0ecda632efd867a1a15') I don't think there is any reason in a package providing it's exact name.

# Maintainer: CuVoodoo pkgname=fungw pkgver=1.2.0 pkgrel=1 pkgdesc="tiny, portable library written in C (C89) that manages dynamic function calls across different programming languages" url="http://www.repo.hu/projects/fungw/" arch=('i686' 'x86_64') license=('LGPL2') depends=('genht') # fungw is not strictly dependant on genht (it also embeds it), but other packages relying on fungw also can optionally use external genht, and we don't want them to use different versions This reasoning is interesting. If it embeds it, can it "provide" genht too?

# Maintainer: CuVoodoo pkgname=librnd3-svn pkgver=r32924 pkgrel=1 pkgdesc="free/open source, flexible, modular two-dimensional CAD engine" url="http://www.repo.hu/projects/librnd/" arch=('i686' 'x86_64') license=('GPL') depends=() Empty depends array can be removed (in other places too).

Marcin Wieczorek

I did not know you don't need to add 'provide' if the name is the same as the package. thanks for pointing it out, I'll remove them in the non-svg packages provides: An array of additional packages that the software provides the features of. The package itself cannot be "additional". At least I've always understood it that way.

...

...

# fungw is not strictly dependant on genht (it also embeds it), but other packages relying on fungw also can optionally use external genht, and we don't want them to use different versions This reasoning is interesting. If it embeds it, can it "provide" genht too?

no, it can't provide genht, it only uses its own copy as fallback if the library is not available. this strategy/dependency was recommended by the author of all this software. Fair enough.

Also I noticed that the signatures are broken (0 byte files). I don't think it even is PGP. In case you ever contact the upstream make sure to mention this and the fact that they should have https. I'm not sure about that tho, because the authors seem to negate the value of HTTPS or at least point out "false sense of security". http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=https Marcin Wieczorek

On 21/07/22 14:54, pcb-rnd@cuvoodoo.info wrote:

On Thu, Jul 22, 2021 at 02:45:38PM +0200, Marcin Wieczorek wrote:

...

Also I noticed that the signatures are broken (0 byte files). I don't think it even is PGP. In case you ever contact the upstream make sure to mention this and the fact that they should have https. I'm not sure about that tho, because the authors seem to negate the value of HTTPS or at least point out "false sense of security". http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=https

I already pointed out that some .asc are missing or empty. that should be fixed in the next release according to the author.

as for the https, I also discussed with the author on IRC, and the http choice is deliberate because the "false" securi ty feeling HTTPS provide are not worth the effort, and he prefers pointing out the anchor of trust issue (as you found in the article).

also the signatures provided on the release page only use x.509 certificates. AFAICS only GPG signatures are supported by PKGBUILD. this is why I did not include the signatures.

Ok. I'm glad that you considered that and already took action. You could always do some prepare() magic to check the sigs. In current case the packages lacks security measures, only the sums provide integrity. Am I right? Marcin Wieczorek

yes, you are right, there is only the sum currently, and the signature is not checked. thanks for mentioning that is could be done in prepare(). I could not find a way to do checks before extraction, since prepare() is only after extraction (not required for checking the archives).

do you know a good package example which also verifies x.509 signatures in prepare() (which does not require large/unusual dependencies)? I'm happy to copy it to these projects.

Openssl would be your only dependency. Prepare extracts the tarball, but it should still be available in the $srcdir, right? And no, I've never seen such example. Marcin Wieczorek