On Mon, Dec 6, 2010 at 12:14 AM, Slash <demodevil@gmail.com> wrote:
> Anyways, judging by the comments in this thread, there is no one tool
> or best place to put something like this, currently (like namcap). If
> the bot will only comment once per package, I guess it won't be too
> intrusive- besides this one-time spam for existing packages

It's an experiment I've been working on for some time. To appease
Heiko I've removed all trace of personality and variety from the form
message.

I've also come across a bug in the AUR. In short, the tarball URL
provided by the RPC interface is different from the tarball taken from
the html page. The RPC tarball is *exactly* what was uploaded. While
the html tarball has been sanitized. So let's say someone uploads
something that is not even a tarball. The AUR fixes this and pushed
it to the html. The RPC link goes to the original, and Mr Robot
complains. Human looks at html tarball and sees nothing wrong.
Confusion abound. I'll remove those comments.

-Kyle
http://kmkeen.com

On Sun, Dec 5, 2010 at 9:26 PM, keenerd <keenerd@gmail.com> wrote:
>
> I've also come across a bug in the AUR. *In short, the tarball URL
> provided by the RPC interface is different from the tarball taken from
> the html page. *The RPC tarball is *exactly* what was uploaded. *While
> the html tarball has been sanitized.
> ...

Christopher Brannon also mentioned this on the aur-dev list, giving
links to the flyspray bug reports as well:
http://mailman.archlinux.org/pipermail/aur-dev/2010-November/001345.html

I don't understand why the URLPath RPC field is necessary if the
source package files always have the same predictable URL...
--
-Justin

On 6 December 2010 03:42, keenerd <keenerd@gmail.com> wrote:
> Thanks for all the input. Â*I'm pushing the posts now and it should be
> done in a few hours. Â*For now it is just doing a single pass, but in
> the future I'll set it up to track the RSS.
>
> There is a lot of fun stuff in the AUR. Â*More stats later. Â*For now,
> here is my favorite:
>
> 472 packages had a single PNG. Â*1 package had 100 PNGs.
>
> For more fun, try to find the bot. Â*He's tagging 4% of packages, so it
> should not be too hard.
>
> -Kyle
> http://kmkeen.com
>

I just got spammed by your bot. You should really omit the warning for
png's. It should be easy to change your script only to check whether
file output contains "ELF", "executable" or "shared object". To
paraphrase your message "I think you can do better."

Anyway, this makes me think that the current AUR guidelines should be
more clear about this issue. To be more precise I mean this part:

After logging in to the AUR web interface, a user can submit a gzipped
tarball (.tar.gz) of a directory containing build files for a package.
The directory inside the tarball should contain a PKGBUILD, any
.install files, patches, etc. (ABSOLUTELY no binaries).

I'm pretty sure binaries originally referred to executables and
libraries (which are in fact executables). My proposal is to change
this sentence accordingly. Either use "ABSOLUTELY no executables" or
"ABSOLUTELY no binaries except for icons."

Also it should be mentioned in Arch Packaging Standards.

opinions?

>
> The problem is that namcap's implementation is not meant for untrusted
> PKGBUILDs. Sourcing those build files is a big security flaw, so we
> can't do that for the AUR.
>

We can create minimal chroot with bash and namcap only. It would
require changes to the infrastructure but it could improve the
PKGBUILDs in AUR a lot.

Here's how it could work:
* user uploads tarball with a package to AUR, the tarball is moved to
the "staging area".
* uploader can see his/her (I wonder how many girls are here :-))
package in AUR interface immediately – this is mostly to prevent
consecutive uploads of the same package. Other users can't see it
until it's checked by namcap.
* create the chroot and check the package using namcap. then of course
clean the chroot
* if there are errors in the package send email/other notification to
the uploader. Otherwise the package is made available to public.
-> it could be interesting to made namcap results available too. The
package "Package Details" could include namcap log somewhere.

On 6 December 2010 10:42, keenerd <keenerd@gmail.com> wrote:
> Thanks for all the input. *I'm pushing the posts now and it should be
> done in a few hours. *For now it is just doing a single pass, but in
> the future I'll set it up to track the RSS.
>
> There is a lot of fun stuff in the AUR. *More stats later. *For now,
> here is my favorite:
>
> 472 packages had a single PNG. *1 package had 100 PNGs.
>
> For more fun, try to find the bot. *He's tagging 4% of packages, so it
> should not be too hard.

I'm not liking this one bit. It's definitely spam to me, since
comments trigger e-mail notifications and I don't want e-mails from
bots just because my package has an image/icon.

Hi all,

been told by the bot, that selinux-flex has a binary (selinux-flex/flex-
arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this
package is just a copy of a [core] package from some time ago, I guess the
original maintainers new, what they were doing, if they included it this way.
So should I do it to not include evil gziped patches?

Thanx, Nicky

--
Don't it always seem to go
That you don't know what you've got
Till it's gone

(Joni Mitchell)

Am Mon, 6 Dec 2010 00:26:22 -0500
schrieb keenerd <keenerd@gmail.com>:

> It's an experiment I've been working on for some time. To appease
> Heiko I've removed all trace of personality and variety from the form
> message.

In most cases there's a reason for having binaries, icons and the like
in a package. And whether such a package actually has a bad quality or
its contents are necessary can't be decided by a bot.

It's pretty the same as the case when someone thought in the past it
was sufficient to just comparing two package names and to sending a
removal request for one of these packages just because a part of the
package names is equal without looking into these packages and without
reading the PKGBUILD.

So such a bot can probably help you to finding possible candidates with
a bad packaging quality, but you have to verify those packages by
yourself. So a bot should at the very most create a list of those
packages for you, but should definitely not write comments to AUR.

Then you should verify the packages on this list by looking into those
packages and reading the PKGBUILDs. Only if you then find a package
which really doesn't respect the policies you can post a comment for
this package manually or create another list with those packages and
let a bot sending the comments to the packages on this second list.

But having a bot sending such comments just because there's
one .desktop file or icon in the package is spam. And think about the
responses of the maintainers or other users to those comments. And
consider that this spam goes into the inboxes of up to hundreds of
people.

Btw., the QA in AUR is usually pretty good, because comments for a
package are usually written pretty fast by other users or TUs if a
package doesn't respect some guidelines, has bugs or a bad quality or
isn't trustworthy.

And if a maintainer doesn't respond to such comments or doesn't fix
those issues users usually send an orphan request to the mailing list to
be able to fix these issues themselves.

So there's usually no need for such a bot.

> I've also come across a bug in the AUR. In short, the tarball URL
> provided by the RPC interface is different from the tarball taken from
> the html page. The RPC tarball is *exactly* what was uploaded. While
> the html tarball has been sanitized. So let's say someone uploads
> something that is not even a tarball. The AUR fixes this and pushed
> it to the html. The RPC link goes to the original, and Mr Robot
> complains. Human looks at html tarball and sees nothing wrong.
> Confusion abound. I'll remove those comments.

I don't know how all the AUR scripts like yaourt, aurbuild, clyde etc.
retrieve the tarballs from AUR, whether they get it from the HTML or the
RPC interface. And I don't know how the HTML interface should sanitize
packages and what you actually mean with sanitize. But I had absolutely
no such problems with AUR packages, yet.

Heiko

On Mon, Dec 06, 2010 at 03:20:06PM +0100, Heiko Baums wrote:
> In most cases there's a reason for having binaries, icons and the like
> in a package. And whether such a package actually has a bad quality or
> its contents are necessary can't be decided by a bot.

In _all_ cases, binaries are not permissable as stated by the AUR
guidelines [1]. Your opinion doesn't change this. A proposal to amend the
guidelines can.

>
> <snip>
>
>
> Btw., the QA in AUR is usually pretty good, because comments for a
> package are usually written pretty fast by other users or TUs if a
> package doesn't respect some guidelines, has bugs or a bad quality or
> isn't trustworthy.

My day job is QA. I assure you, based on what Kyle found and in my own
personal experience, it's not that good. A lot of things do get caught.
A lot of things don't. How many packages still don't have an arch=
declaration, or still make reference to $startdir? While less offensive,
I could give you a list of packages that have 2777 permissions on the
tarballed folder. Kyle hasn't even touched parsing the PKGBUILD itself,
but I might be tempted to borrow his database and do such a thing.

>
> And if a maintainer doesn't respond to such comments or doesn't fix
> those issues users usually send an orphan request to the mailing list to
> be able to fix these issues themselves.
>
> So there's usually no need for such a bot.
>
> > I've also come across a bug in the AUR. In short, the tarball URL
> > provided by the RPC interface is different from the tarball taken from
> > the html page. The RPC tarball is *exactly* what was uploaded. While
> > the html tarball has been sanitized. So let's say someone uploads
> > something that is not even a tarball. The AUR fixes this and pushed
> > it to the html. The RPC link goes to the original, and Mr Robot
> > complains. Human looks at html tarball and sees nothing wrong.
> > Confusion abound. I'll remove those comments.
>
> I don't know how all the AUR scripts like yaourt, aurbuild, clyde etc.
> retrieve the tarballs from AUR, whether they get it from the HTML or the
> RPC interface. And I don't know how the HTML interface should sanitize
> packages and what you actually mean with sanitize. But I had absolutely
> no such problems with AUR packages, yet.

As an author of one of these abominations, I (cower) make an assumption
that the package can be found at /packages/%s/%s.tar.gz, simply because
the URLPath provided in the JSON reply is not trustworthy. It seems as
though the database is populated on upload, rather than after parsing,
which leads to these problems. It's not really a big deal. Frankly, if
any change were to be made, I'd vote for URLPath to be removed from the
JSON reply.

dave

[1] https://wiki.archlinux.org/index.php/AUR

Dave Reisner <d@falconindy.com> writes:

> As an author of one of these abominations, I (cower) make an assumption
> that the package can be found at /packages/%s/%s.tar.gz, simply because
> the URLPath provided in the JSON reply is not trustworthy. It seems as
> though the database is populated on upload, rather than after parsing,

I think some of the old database entries are just stale. They weren't
updated to reflect changes to the code. Case in point, hocr.
Here's a curl command to retrieve the JSON data for that package:
curl 'http://aur.archlinux.org/rpc.php?type=info&arg=hocr'

-- Chris

On Mon, Dec 6, 2010 at 4:59 AM, Nicky726 <nicky726@gmail.com> wrote:
> been told by the bot, that selinux-flex has a binary (selinux-flex/flex-
> arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this
> package is just a copy of a [core] package from some time ago, I guess the
> original maintainers new, what they were doing, if they included it this way.
> So should I do it to not include evil gziped patches?

Evil is such a strong word. It is just without benefit. Disturbs the
transparency of things. Technically against the rules.

Zipped patches was an edge case. Here, I chose to take a strict
interpritation of the edge cases. It is only a comment after all,
very little of consequence. Besides, Arch tries hard to not patch
things :-)

But thank you for taking the time to read and respond. So many
maintainers ignore comments.

-Kyle
http://kmkeen.com