allow .gz, .tgz, and .zip attachments

This is intentional. We only want easily accessible files to be uploaded.

Please remember to actually *reopen* issues when appropriate.

changing title to reflect my feeling about the issue.

I also failed to attach .module files a couple of times (tiny patch-size modules ARE accessible IMO).

Also I think there are still use cases for attaching .tar.gz, like I did for example here: http://drupal.org/node/176436 - Attaching a whole new version of a module as contribution in queue, mainly for the maintainer, but also for anyone interested before he come. Tricky thing now, without archive requires multiple follow-ups just to attach files (and still would fail due to the above).

You can (and should) do multi-file diffs.

See http://drupal.org/patch/create for the way to do that.

greggles, issues are not only used to attach patches. As the nice mockups showed by Kristjan (AFAIR), different attachment types might even need different presentation after all. Images might be previewed, etc.

Anyway, back to the point. I for one often attach tgz files with test data for language imports or I see people doing tgz attachments instead of binary diffs for new/changed binary files (which I think is safer then moving binary diffs around).

I know, but there are cases, such as brand new file(s), where patch/diff plus reference to some irrelevant old file (in case of changed files where not much actually remains unchanged) is much more difficult for both sides (and requires extra tool - i.e. patch utility is not present at every end-users machine), than plainly attaching the file itself. A few times I saw people on a thread to resort to adding '.txt' just to make the process easier for everyone.

It might be the case particularly for support-requests: Small helper-files not intended to be ever commited into CVS, created just to help end-user. Why require him to use extra tools, then?

Anyway, thanks for response. I was just trying to give feedback, not pushing on this.

I think they should be allowed. I get tired of having to change the extension from .txt to .zip or whatever because someone had to change the extension to get the upload allowed.

Michelle

i'd be in favor of allowing these attachment types.

a) there are legitimate use-cases (new modules, complete re-writes, etc).

b) in these cases, patches aren't always appropriate, and are frequently hard to create and use if they touch a lot of files (especially files that might be changing).

c) ever since the new attachment whitelist functionality went in and we started preventing .gz and .tgz files, people have simply subverted the rules by renaming their files to .txt before uploading. it isn't just newbies trying to get around this restriction, i've seen senior members of the community resort to the same thing in situations where a patch simply makes no sense.

That said, being able to attach multiple files to an issue or followup (which is now possible thanks to http://drupal.org/node/18920 -- you can start playing with this functionality on http://scratch.drupal.org already) will remove the need for a lot of .(tar|tgz|zip) attachments, but I still think there are times when they'd be useful and easier to work with, so we should just go back to allowing them.

Unless there's a clear, well-supported, convincing argument against this, I'm just going to go ahead and re-enable .(gz|tgz|zip) in this whitelist in the next day or two.

Let me express my support for the idea again, and remind that also .module files are problem (and perhaps more, like .info etc - untested). http://drupal.org/node/117172 is an example of .patch usage where it makes no sense IMO: A brand new module/info pair, less than two screens in size, intended for direct use by end-users.

The problem is that we don't know what is in tarballs and other packed stuff, it might be malicious, copyrighted or whatever.

Good point - but that applies to all files, regardless the exact format used IMO.

There are exploits for .pdf files, but we allow those. Hell, on some lame operating systems, there are exploits through various image formats, too. :( As far as I know, GNU was never stupid enough to write their tools in a way that allowed uncompressing a .gz or unpacking a .tgz to actually execute arbitrary code. In the nearly 20 years I've been using GNU tools, I've never heard of such an exploit. Of course, .zip archives aren't GNU, but I still think we should allow those, too.

As to copyrighted materials and/or non-GPL code -- we have that problem already, and preventing these archive file extensions doesn't help us. Nothing stops someone from committing the non-GPL code directly to the contrib repo except when people happen to notice and point it out. Certainly nothing stops them from uploading it as a patch, or as a .tgz.txt file.

I appreciate what a pain in the ass it is to try to keep this stuff off our servers and out of our repo, but preventing archive attachments doesn't help, and makes things more difficult for people who are genuinely trying to contribute.

If someone feels strongly about the warning messages about attachments to issues, feel free to create a new issue and roll a patch for it, but I think this particular request should be resolved and the archive extensions should be allowed. I'll still give a little more time in case a real reason to continue our current practice surfaces, but at this point, I don't see that happening.

Um, I think this got out of hand a bit. The actual issue is that the error message is lying about the set of accepted extensions, see #3.

Today, I bumped my nose to the restriction, needing to attach an SQL dump for someone else's testing purposes. Yet another xxx.sql.txt uploaded :-(

This is a very old issue, but it seems that it should be closed. I am able to attach .tar.gz without problems, although the extension is renamed to .tar_.gz. Changing status to fixed.

Dave