Il 05/03/2016 19:20, iamjacksemail@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_submissio... [2] https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites -- Fabio Castelli aka Muflone