On Tue, Nov 30, 2010 at 8:48 AM, Dmitriy Sintsov ques...@rambler.ru wrote:
* Bryan Tong Minh bryan.tongm...@gmail.com [Tue, 30 Nov 2010 08:44:43
+0100]:
I think that the most recent version should be sufficient. I don't
think Java would break backwards compatibility: users wouldn't be
happy
* Marco Schuster ma...@harddisk.is-a-geek.org [Tue, 30 Nov 2010
11:05:09 +0100]:
You can create a zip easily on all major OSes with drag'n'drop.
Windows supports it IIRC from Win 98 SE and up, a standard Linux by
the tools the desktop installs (for KDE, it once was Ark), and MacOS
also
* Marco Schuster ma...@harddisk.is-a-geek.org [Tue, 30 Nov 2010
11:05:09 +0100]:
You can create a zip easily on all major OSes with drag'n'drop.
Windows supports it IIRC from Win 98 SE and up, a standard Linux by
the tools the desktop installs (for KDE, it once was Ark), and MacOS
also
2010/11/30 Dmitriy Sintsov ques...@rambler.ru:
* Bryan Tong Minh bryan.tongm...@gmail.com [Tue, 30 Nov 2010 08:44:43
+0100]:
I think that the most recent version should be sufficient. I don't
think Java would break backwards compatibility: users wouldn't be
happy if their old jar suddenly
On Tue, Nov 30, 2010 at 9:40 PM, Roan Kattouw roan.katt...@gmail.com wrote:
We don't necessarily want ZIP uploads at Wikimedia, but it's not
unreasonable to want to upload OpenOffice documents. Since the OO
formats are ZIP-like, blocking ZIPs blocks those too.
Roan Kattouw (Catrope)
Although
2010/11/25 bawolff bawolff...@gmail.com:
Personally I think it would be nicer if you could associate source
files with the final files.
Yeah, this was discussed a bit earlier in this thread. As far as I can
tell, that approach adds a fair degree of complexity (requirement of
tracking a whole
2010/11/29 Erik Moeller e...@wikimedia.org:
As far as I understand the pure security (as opposed to content)
concerns, these fall primarily into these categories:
* client-side execution of unsafe formats using designated
applications (embedded macros, references to other malicious content
Roan Kattouw wrote:
An alternative [to rejecting all ZIP files] would be to parse the
entire zip directory and to reject any archives that contain a file
with a .class extension. I can’t vouch for this method. **If you did
this, the zip library you used would have to be exactly as tolerant of
On Mon, Nov 29, 2010 at 9:29 PM, Roan Kattouw roan.katt...@gmail.com wrote:
An alternative [to rejecting all ZIP files] would be to parse the
entire zip directory and to reject any archives that contain a file
with a .class extension. I can’t vouch for this method. **If you did
this, the zip
Bryan Tong Minh wrote:
On Mon, Nov 29, 2010 at 9:29 PM, Roan Kattouw roan.katt...@gmail.com wrote:
An alternative [to rejecting all ZIP files] would be to parse the
entire zip directory and to reject any archives that contain a file
with a .class extension. I can’t vouch for this method. **If
* Bryan Tong Minh bryan.tongm...@gmail.com [Tue, 30 Nov 2010 08:44:43
+0100]:
I think that the most recent version should be sufficient. I don't
think Java would break backwards compatibility: users wouldn't be
happy if their old jar suddenly stops working on a new JVM.
Why an outdated and
On 25 November 2010 07:58, Bryan Tong Minh bryan.tongm...@gmail.com wrote:
I think you are taking the wrong approach here, altough I agree with
MZMcBride's reply to your mail From a social and technical
perspective, this proposal is horribly hackish. [...] Given the
current parameters, this
Erik Moeller wrote:
[Kicking this thread back to life, full-quoting below only for quick
reference.]
I've collected some additional notes on this here:
http://commons.wikimedia.org/wiki/Commons:Restricted_uploads
Would appreciate feedback will circulate further in the Commons community.
Message: 5
Date: Wed, 24 Nov 2010 15:46:24 -0800
From: Erik Moeller e...@wikimedia.org
Subject: Re: [Wikitech-l] Commons ZIP file upload for admins
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Message-ID:
aanlktimd7kxngs4azgpanr_84ok_th9t1dsanc7st...@mail.gmail.com
Content
[Kicking this thread back to life, full-quoting below only for quick reference.]
I've collected some additional notes on this here:
http://commons.wikimedia.org/wiki/Commons:Restricted_uploads
Would appreciate feedback will circulate further in the Commons community.
Thanks,
Erik
2010/10/25
Erik Moeller wrote:
I've collected some additional notes on this here:
http://commons.wikimedia.org/wiki/Commons:Restricted_uploads
Would appreciate feedback will circulate further in the Commons community.
From a social and technical perspective, this proposal is horribly hackish.
The
On Thu, Nov 25, 2010 at 12:46 AM, Erik Moeller e...@wikimedia.org wrote:
[Kicking this thread back to life, full-quoting below only for quick
reference.]
I've collected some additional notes on this here:
http://commons.wikimedia.org/wiki/Commons:Restricted_uploads
Would appreciate
@2010-10-26 03:45, Erik Moeller:
2010/10/25 Brion Vibberbr...@pobox.com:
In all cases we have the worry that if we allow uploading those funky
formats, we'll either a) end up with malicious files or b) end up with lazy
people using and uploading non-free editing formats when we'd prefer them
On Tue, Oct 26, 2010 at 6:50 AM, Max Semenik maxsem.w...@gmail.com wrote:
Instead of amassing social constructs around technical deficiency, I
propose to fix bug 24230 [1] by implementing proper checking for JAR
format. Also, we need to check all contents with antivirus and
disallow certain
Hello all,
for some types of resources, it's desirable to upload source files
(whether it's Blender, COLLADA, Scribus, EDL, or some other format),
so that others can more easily remix and process them. Currently, as
far as I know, there's no way to upload these resources to Commons.
What would
On 25.10.2010, 23:02 Erik wrote:
Hello all,
for some types of resources, it's desirable to upload source files
(whether it's Blender, COLLADA, Scribus, EDL, or some other format),
so that others can more easily remix and process them. Currently, as
far as I know, there's no way to upload
On 10/25/2010 12:02 PM, Erik Moeller wrote:
Hello all,
for some types of resources, it's desirable to upload source files
(whether it's Blender, COLLADA, Scribus, EDL, or some other format),
so that others can more easily remix and process them. Currently, as
far as I know, there's no way to
On Mon, Oct 25, 2010 at 3:50 PM, Max Semenik maxsem.w...@gmail.com wrote:
Instead of amassing social constructs around technical deficiency, I
propose to fix bug 24230 [1] by implementing proper checking for JAR
format.
Does that bug even affect Wikimedia? We have uploads segregated on
their
Aryeh Gregor wrote:
On Mon, Oct 25, 2010 at 3:50 PM, Max Semenik maxsem.w...@gmail.com wrote:
Instead of amassing social constructs around technical deficiency, I
propose to fix bug 24230 [1] by implementing proper checking for JAR
format.
Does that bug even affect Wikimedia? We have
On Mon, Oct 25, 2010 at 10:09 PM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
On Mon, Oct 25, 2010 at 3:50 PM, Max Semenik maxsem.w...@gmail.com wrote:
Instead of amassing social constructs around technical deficiency, I
propose to fix bug 24230 [1] by implementing proper checking for JAR
On Mon, Oct 25, 2010 at 10:51 PM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
On Mon, Oct 25, 2010 at 10:09 PM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
On Mon, Oct 25, 2010 at 3:50 PM, Max Semenik maxsem.w...@gmail.com wrote:
Instead of amassing social constructs around
Martijn Hoekstra wrote:
Should we also be exploring any possibly malicious archives inside
archives recursively, or is just making sure the archive itself is
good is good enough?
I think that we should block such files.
Also note that we can't recursively analyse everything since that would
On Mon, Oct 25, 2010 at 1:05 PM, Michael Dale md...@wikimedia.org wrote:
Its most ideal if we actually support these formats, so we can do thing
like thumbnails, basic meta data etc. Failing that its better to support
a given file extension, then it is to support zip files. This way if in
28 matches
Mail list logo
