JFFS3 document

JFFS3 document

[Artem B. Bityuckiy]

Hi,

I wanted to inform that now the http://www.linux-mtd.infradead.org/
Linux MTD web site has the JFFS3-related section.

The summary of our JFFS3 discussions could be found at http://www.linux-
mtd.infradead.org/tech/JFFS3design.pdf document. It is also accessible
via MTD web page. The document is generated from the
fd/jffs3/JFFS3design.tex file, so one can contribute even directly
editing it.

Any remarks and suggestions are welcomed.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: JFFS3 document

[Michael]

--- "Artem B. Bityuckiy" <dedekind@infradead.org> wrote:

..
> The summary of our JFFS3 discussions could be found at
> http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf document.
> It is also accessible via MTD web page. The document is generated
> from the fd/jffs3/JFFS3design.tex file, so one can contribute
even
> directly editing it.
> 
> Any remarks and suggestions are welcomed.

Instead of editing this file via CVS, would it be possible (and a
good idea) to use a wiki?  That would make it really easy (and time
efficient) for anyone to modify it.

Mike

Re: JFFS3 document

[Josh Boyer]

On Wed, 2005-01-26 at 14:51, Michael wrote:
> --- "Artem B. Bityuckiy" <dedekind@infradead.org> wrote:
> 
> ..
> > The summary of our JFFS3 discussions could be found at
> > http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf document.
> > It is also accessible via MTD web page. The document is generated
> > from the fd/jffs3/JFFS3design.tex file, so one can contribute
> even
> > directly editing it.
> > 
> > Any remarks and suggestions are welcomed.
> 
> Instead of editing this file via CVS, would it be possible (and a
> good idea) to use a wiki?  That would make it really easy (and time
> efficient) for anyone to modify it.
> 

That was brought up on IRC and vetoed.  Wikis tend to get spammed with
useless or out-dated information, and it's another application for the
server to have to keep up are the reasons I believe.

You could do locked pages in a Wiki, but that's not much different than
having CVS access.  :)

josh

Re: JFFS3 document

[David Woodhouse]

On Wed, 2005-01-26 at 15:30 -0600, Josh Boyer wrote:
> > Instead of editing this file via CVS, would it be possible (and a
> > good idea) to use a wiki?  That would make it really easy (and time
> > efficient) for anyone to modify it.
> > 
> That was brought up on IRC and vetoed.  Wikis tend to get spammed with
> useless or out-dated information, and it's another application for the
> server to have to keep up are the reasons I believe.

It wasn't really vetoed. I just said that _I_ didn't want to run a Wiki,
for much those reasons. I also pointed out that having a minor barrier
to entry wasn't _necessarily_ a bad thing. Hell, most days even I
shouldn't be permitted to commit to it. Why should we open it to the
world? :)

Send patches if you want to make changes. If you make a habit of sending
patches we actually want to apply, we'll give you an account and you can
do it yourself. That's the way it's always worked for the code, and it
doesn't seem to have been much of a problem.

-- 
dwmw2

Re: JFFS3 document

[Jörn Engel]

On Thu, 27 January 2005 09:47:31 +0000, David Woodhouse wrote:
> On Wed, 2005-01-26 at 15:30 -0600, Josh Boyer wrote:
> > > Instead of editing this file via CVS, would it be possible (and a
> > > good idea) to use a wiki?  That would make it really easy (and time
> > > efficient) for anyone to modify it.
> > > 
> > That was brought up on IRC and vetoed.  Wikis tend to get spammed with
> > useless or out-dated information, and it's another application for the
> > server to have to keep up are the reasons I believe.
> 
> It wasn't really vetoed. I just said that _I_ didn't want to run a Wiki,
> for much those reasons. I also pointed out that having a minor barrier
> to entry wasn't _necessarily_ a bad thing. Hell, most days even I
> shouldn't be permitted to commit to it. Why should we open it to the
> world? :)

Plus, Wikis tend to be instant security problems.  The situation
appears to be so bad that anyone with average exploit knowledge can
read the sources and control some new machines within a rainy
afternoon.  So you'd have to keep a seperate machine just for wiki.

Jörn

-- 
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000

Re: JFFS3 document / wiki [OT]

[Cam]

Jörn

> Plus, Wikis tend to be instant security problems.  The situation
> appears to be so bad that anyone with average exploit knowledge can
> read the sources and control some new machines within a rainy
> afternoon. 

Can you back that statement up with an example please? I wasn't aware 
that wikis were so dangerous! :)

I run a wiki which had some problems with spam but it didn't go beyond 
that, and I've never heard of a wiki that caused security problems. IMHO 
they provide a reasonable compromise between high security and good 
features.

-Cam


-- 
camilo@mesias.co.uk                                                 <--

Re: JFFS3 document / wiki [OT]

[Jörn Engel]

On Thu, 27 January 2005 16:10:38 +0000, Cam wrote:
> 
> >Plus, Wikis tend to be instant security problems.  The situation
> >appears to be so bad that anyone with average exploit knowledge can
> >read the sources and control some new machines within a rainy
> >afternoon. 
> 
> Can you back that statement up with an example please? I wasn't aware 
> that wikis were so dangerous! :)

Neither was I before attending last years ccc.
http://www.ccc.de/congress/2004/

Various bits of information on this were spread all over the place:
o Code examples of mysql - tons of buffer overflows.
o Code examples of php - same.
o Various hacks of machines based on either php or mysql
  vulnerabilities.
o Some specific problems with some wiki implementations.

Considering that most wikis use php, mysql or both, you can pretty
much get the idea.  I cannot point to specific vulnerabilities or
exploits, but the only thing stopping me from owning your wiki is my
lack of interest.  Cooking up something new is horribly simple.  So
you might want to move it somewhere, either to a dedicated machine or
to a vserver/chroot/jail.

And if you have too much time on your hands, security audits on php
and mysql wouldn't hurt.

Jörn

-- 
All art is but imitation of nature.
-- Lucius Annaeus Seneca

Re: JFFS3 document / wiki [OT]

[jasmine]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 326 bytes --]



On Thu, 27 Jan 2005, [iso-8859-1] Jörn Engel wrote:

> And if you have too much time on your hands, security audits on php
> and mysql wouldn't hurt.

Or just do what anyone with taste does and use Java servlets or JSP on top 
of a PostgreSQL database.  I'm pretty sure there are Java-based wikis out 
there.

-J.

Re: JFFS3 document / wiki [OT]

[Jörn Engel]

On Thu, 27 January 2005 16:37:47 +0000, jasmine@linuxgrrls.org wrote:
> On Thu, 27 Jan 2005, [iso-8859-1] Jörn Engel wrote:
> 
> >And if you have too much time on your hands, security audits on php
> >and mysql wouldn't hurt.
> 
> Or just do what anyone with taste does and use Java servlets or JSP on top 
> of a PostgreSQL database.  I'm pretty sure there are Java-based wikis out 
> there.

Not sure how much better postgres is.  Java surely helps.  If all
input is checked for "normalness" before being passed to the dbms,
that would help as well.

Sadly the "normalness" includes things like domain names being shorter
than 100 bytes and other non-obvious stuff.

Jörn

-- 
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918

Re: JFFS3 document / wiki [OT]

[Jörn Engel]

On Thu, 27 January 2005 17:38:45 +0100, Jörn Engel wrote:
> 
> Various bits of information on this were spread all over the place:
> o Code examples of mysql - tons of buffer overflows.
> o Code examples of php - same.

Didn't find a video, but here are some slides:
http://www.ccc.de/congress/2004/fahrplan/files/363-literarisches-code-quartett-slides.pdf

Jörn

-- 
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike

Re: JFFS3 document / wiki [OT]

[Cam]

Jörn

> Various bits of information on this were spread all over the place:
> o Code examples of mysql - tons of buffer overflows.
> o Code examples of php - same.
> o Various hacks of machines based on either php or mysql
>   vulnerabilities.
> o Some specific problems with some wiki implementations.
> 
> Considering that most wikis use php, mysql or both, you can pretty
> much get the idea.  I cannot point to specific vulnerabilities or
> exploits, but the only thing stopping me from owning your wiki is my
> lack of interest.

Sorry but I'm not convinced. The link is interesting but there is no 
mention of wikis. Also, php and mysql are used widely for other 
purposes, if it was as bad as you say, we would be in some kind of web 
apocalypse, which we're not. There are other wikis too (Java based or 
Perl/CGI in my case).

Cheers,

-Cam

-- 
camilo@mesias.co.uk                                                 <--

Re: JFFS3 document / wiki [OT]

[Jörn Engel]

On Thu, 27 January 2005 18:27:01 +0000, Cam wrote:
> 
> Sorry but I'm not convinced. The link is interesting but there is no 
> mention of wikis. Also, php and mysql are used widely for other 
> purposes, if it was as bad as you say, we would be in some kind of web 
> apocalypse, which we're not. There are other wikis too (Java based or 
> Perl/CGI in my case).

Translated to plain English, my reasoning puts php/mysql into the same
league as wuftpd or bind.  Expect to update those packages twice a
year for security reasons.  And never run it on machines that
criminals might care about - they will simply create a new exploit and
attack the machine before you get a chance for updates.

But if you're fine with that, feel free to use the software.

Jörn

-- 
Victory in war is not repetitious.
-- Sun Tzu