On Mon, Feb 21, 2011 at 01:46:33PM +0100, Dieter Plaetinck wrote: > On Mon, 21 Feb 2011 12:19:08 +0100 > Lukas Fleischer <archli...@cryptocrack.de> wrote: > > > > > Moreover, I've heard of some encoding issues with users just > > > > copy-pasting files from the AUR frontend. > > > > > > this is kindof vague. "encoding issues"... issues at AUR side or > > > client side? if the former, that would be a bug that could get > > > fixed. > > > > I'm not sure. Probably both. It's obvious that if you copy and paste > > something from your browser, it won't be exactly the same as in the > > original tarball. > > it's not obvious to me. Am I missing something? AFAIK, I should really > get the same contents of text files pasted on my system (maybe encoded > differently but that doesn't matter) provided all the characters shown > can be decoded and encoded on my system. (and if that's not possible, > then it's up to the user to configure his locales properly)
Yes, it's probably an encoding issue in most cases. And it's the rendering engine that doesn't always display stuff one-to-one. Best example are HTML files: If you copy the rendered page from some browser, you'll certainly not get the original HTML source again. That might be a bad example as, for the user, the differences are obvious in this case, but I'm sure that there are "better" ones around (I've heard of users reporting such things). > > > > Generally, everyone should download and use the tarballs to build > > > > packages. > > > > > > Yes, but I'm not talking about building packages, I'm talking about > > > getting a quick idea of what the package contains and how it gets > > > built/installed. for that, the "files" previous was very useful. > > > > How often do you do that? Why don't you just download the tarball and > > check its contents? I also can't imagine a lot of cases where the > > PKGBUILD preview doesn't give you an idea of what a package does. > > > > If there really is need for such a thing, I'd also say this is > > something to do on the client side. AUR helpers might want to > > implement this. Or you can just check the cgit interface of the > > unofficial Git clone of the AUR [1]. > > Well, the problem is, if it would be all about the PKGBUILD alone, > there would be no problem. But the mere fact that an aur > contributor needs to upload source tarballs suggests there could be > more stuff in there (install files, licence files, or even "dirtier" > stuff), I could indeed look at the PKGBUILD but then I would need to > inspect all the source code of the PKGBUILD which is much more mental > work, which I try to avoid when I just want to get an idea of "what > does this package contain" > > the reason I do this through the AUR webinterface is.. well, because > there is a web interface. it's a bit cumbersome that I can do the > package searching, looking at comments, looking at package info, ... in > the webinterface, but not getting an idea of the contents of the source > tarball. Well, you still have a listing of all source files on the package details page - there are just no direct links to their contents. Can you give me one single example where you really need to have a quick look at the content of some source file to get an idea of what a package does? ".install" files only add users/groups, run some database upgrade scripts or display install messages in 95% of cases. License files will certainly never be needed to be inspected to make out the purpose of a package. The intention of patches can be guessed from their file names in most cases. If there really is need for a deep analysis, you can always download and extract the source tarball which should take about 5 seconds. > Maybe another point which is interesting to think about: you mentioned > it would take several security precautions in AUR to prevent malicious > source tarballs. By not doing this in AUR itself, doesn't that mean > that every single AUR frontend should support this? > If, as a user, I want to look at the source package, my aur client > needs to fetch it, and extract it but it will need to do all those > precautions you mentioned before. If AUR would take care of that, > clients could be simpler. Nope. Almost all of these things are harmful on the server side only. Your local system can't be DoS'ed by uploading malicious tarballs as there's no uploading to the clients. You decide which source tarballs to download. You can also abort the download/extraction process at any time. You won't bother about having a symlink to "/etc/passwd" somewhere in your directory tree. Giving read access to arbitrary files to everyone on a server is a much bigger issue. Trust me. XSS can only be done on the server. Executable scripts can't be executed by some remote attacker if they're just located somewhere inside your home directory. CGI/PHP scripts on the webserver are executable if the server isn't configured correctly. The only issue that might affect the end users as well is "ZIP bombs". Most users will probably notice such a thing before it is entirely extracted, just interrupt tar(1)/gzip(1) and send a removal request to aur-general, however. We also don't aim at moving functionality from the client side to the server side. It's the other way round. Keep the AUR simple, do complex and additional/optional operations on the client side.
