But is deleting the package really the best route? Why not let the maintainer know and let them fix the package? This is not a virus isn't it? On Wed, Mar 30, 2016, 16:22 Alad Wenter wrote:

On 30.03.2016 16:04, LoneVVolf wrote:

...

Hi,

The package airvpn-portable [1] installs files in userfolders [2] and imo should be deleted ASAP. I filed a deletion request,but felt this issue is serious enough to warn about this package.

I would like to advise users to remove it from their systems immediately, but don't know if additonal steps are needed to clean up the mess it created,.

Lone_Wolf

[1] https://aur.archlinux.org/packages/airvpn-portable/ [2] https://bbs.archlinux.org/viewtopic.php?id=210720

peazip-portable (by the same maintainer) has similar issues.

Alad

+1 for quick deletion. No further questions. Wed, 30-03-2016 a las 17:59 +0200, stefan-husmann@t-online.de wrote:

-----Original-Nachricht----- Betreff: Re: [aur-general] AUR airvpn-portable changes files in userfolders, DO NOT INSTALL Datum: 2016-03-30T17:13:15+0200 Von: "William Di Luigi" An: "Discussion about the Arch User Repository (AUR)"

But is deleting the package really the best route? Why not let the maintainer know and let them fix the package? This is not a virus isn't it?

I would consider such anti-pattern as a virus, as it could potentially overwrite/destroy data out of pkg manager domain. Think about production environments. This is unacceptable.

-- The maintainer has some other packages for airvpn which do not try to be "portable" in the MS-Windows manner.

AUR packages may not change the users' HOME directories, that is the rule. 1+ for quick deletion.

Best Regards Stefan -- ======================================================================  GPG 0x8C00BA074CA6E08B -- https://www.libcrack.so/

Rules of submission: https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submissio... On Wed, 30 Mar 2016 at 21:41 Ben Oliver wrote:

As a novice to this field, I'd like to ask for a clarification. These are the 'rules' as I understand them:

- Packages must not touch HOME when being installed - Auto-generated local config files are only created when a program is run/first run by the the user, not when it is installed

Is this correct?

On 2016-03-30 18:51, Borja Ruiz wrote:

+1 for quick deletion. No further questions.

Wed, 30-03-2016 a las 17:59 +0200, stefan-husmann@t-online.de wrote:

...

-----Original-Nachricht----- Betreff: Re: [aur-general] AUR airvpn-portable changes files in userfolders, DO NOT INSTALL Datum: 2016-03-30T17:13:15+0200 Von: "William Di Luigi" An: "Discussion about the Arch User Repository (AUR)"

But is deleting the package really the best route? Why not let the maintainer know and let them fix the package? This is not a virus isn't it?

I would consider such anti-pattern as a virus, as it could potentially overwrite/destroy data out of pkg manager domain. Think about production environments. This is unacceptable.

...

-- The maintainer has some other packages for airvpn which do not try to be "portable" in the MS-Windows manner.

AUR packages may not change the users' HOME directories, that is the rule. 1+ for quick deletion.

Best Regards Stefan

Note that this package does *not* write to any file in $HOME, but instead it packages certain files to be installed in $HOME. pacman would still complain if any package's file would conflict with an existing one. Correct me if I am wrong, but even though this package clearly violates the packagin standards, I do not believe it to be that critical that we need to make a big deal of it. The .install file does some things which could in theory delete user data (e.g. `ln -sf'). however it does so in a directory that belongs to the package, which is expected behaviour in .install files.

On 2016-03-30 20:17, Frederik “Freso” S. Olesen wrote:

Den 30-03-2016 kl. 20:07 skrev respiranto:

...

The .install file does some things which could in theory delete user data (e.g. `ln -sf'). however it does so in a directory that belongs to the package, which is expected behaviour in .install files.

If it's in $HOME it doesn't belong to the package.

I just created a test package. $ pacman -Qo $HOME/example /home/respiranto/example is owned by test 0.1-1 reference PKGBUILD: ------------------- pkgname=test pkgver=0.1 pkgrel=1 arch=('any') package() { mkdir -p "$pkgdir$HOME" echo "123" > "$pkgdir$HOME/example" }