[aur-general] re-instate mkinitcpio-nban

[Muflone]

Il 05/03/2016 19:20, iamjacksemail at hackermail.com ha scritto:
>> As explained by mail, I don't consider this software suitable to submit in the AUR.
> 
>> 1) the package is poorly written (see AUR guidelines for packaging[1])
> How so? I moved the tar.gz to ninjaos.org. The package complies with
> specifications.

Apart the limited usefulness or extremely specialized work of this
package [1] and the high risk of damages that this package could do if
wrongly used (to me these are enough reasons to not publish such package
in the AUR), here're a couple of hints:

- the package doesn't describe itself at all, it provides only a generic
description without any information on what the tool does

- the URL website is unhelpful to the user as it doesn't contain any
content or help for the user

- the base and base-devel groups dependencies are assumed as
pre-requisites of every package in the AUR [2]

- the package installs files  untracked by pacman

- there's no point in showing the help on every package upgrade

- the path /usr/share/scripts is not a valid path where to place files


> 2) the software itself is _really_ poorly written
> 
> Can you explain this one? It follows a consistant style, makes use
> of functions, and works exactly as its supposed to. There are
> no magic numbers, local variables are declared as such
> and uses best practices for shell scripting.

- The script lacks any warning and user confirmation or checks against
wrong arguments

- The script assumes there's a separated /boot partition

- The script remounts the boot partition, ignoring the user choice to
have his boot partition mounted read-only or read-write (first remount
it as read-write then mount it read-only)

- The script heavily uses sudo but the default sudo configuration
doesn't give access to regular users.

- The sudo command it's not supposed to be used for each command, if the
script needs root access (and it needs, see the use of the command sync)
then check if the user is root instead of executing many calls to sudo
(and the root user doesn't require sudo).

- The script moves files in the file system even those tracked by pacman
rendering them untracked


> 3) the software itself is a mere bash script that wipes all the drives with zeros
> 
> A. Actually, it runs in ash(almquist shell), not bash (bourne again shell).
> the two are very diffrent.

Yep, this is partially right (the package uses bash for some things and
ash for the bootandnuke.sh script) but this doesn't change at all the
package content.


> B. mkinitcpio itself is a BASH script.

mkinitcpio is a tool which is continuously useful for the system.
shuriken_forge is a once-use tool with a very limited (and doubtful) scope.


> C. The program is a "boot'n'nuker". Its supposed to zerofill all devices. Its
> a valid security program for end of life'ing a computer so it can be
> safely disposed of without risk of data recovery by an attacker.

If you want to provide an "OS" to dispose old hardware then distribute
your "OS" from your website. What's the point in creating a package that
produces such minimal "OS" ?

> Also, NBAN follows the Arch Way. It is simple, written in shellcode.

There's nothing Arch-ish in some mere bash+ash scripts.


The best hint that I could give you is to distribute the shuriken disk
images from your website (as every OS in the world) and properly
document its use in your website, as dban.org presents.
Explain what it it, what it does, how this is done, how to burn the
image and these things. There's no need for a package that produces disk
images to boot to wipe all the data from the booted system.

Best regards

[1]
https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submission
[2] https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites


-- 
Fabio Castelli aka Muflone