MinGW - Minimalist GNU for Windows

On 3/20/07, jacraig@... <jacraig@...> wrote:
> A while ago there was some discussion at length about the MinGW website.  I
> ignored it mostly because it hinged on an argument between CVS and SVN.

And IIRC something about total responsibility and editorship what
drove the web site to the current state.

> Where do we stand on the website?

The main problem is that we need hosting. SF is insecure by design. I
can offer my DreamHost plan, but it is unlikely that my offer will be
accepted. There were also some talks about SourceWare hosting, so as a
last resort we can use their facilities.

> Do we simply need to update it?

No. We need to setup a CMS for it and migrate content (the last thing
is the one I could be able to help with). There was a very nice
MediaWiki about MinGW somewhere, but the common opinion was to try
Drupal. Its new version 5 looks very promising. The problem was that
Drupal hadn't had wiki module and we've got a lot of wiki pages.

> Are there updates already in the pipeline that simply need to be posted?
> Do we want it revamped?

Definitely.

> Sorry to bring up the topic again, but depending on what
> exactly needs to be done I might be willing to lend my efforts to the
> website.

Exactly:
1. Decide hosting options.
2. Install Drupal.
3. Tune Drupal.
4. Migrate content.
5. Tune Drupal even more, add a bits of design.

-- 
--anatoly t.

techtonik writes:
> 
> No. We need to setup a CMS for it and migrate content (the last thing
> is the one I could be able to help with). There was a very nice
> MediaWiki about MinGW somewhere, but the common opinion was to try
> Drupal. Its new version 5 looks very promising. The problem was that
> Drupal hadn't had wiki module and we've got a lot of wiki pages. 
> 

Is Drupal set in stone?  I've worked on one and built another Plone site 
from the ground up recently and have become very comfortable with it, as 
well as a big fan.  Zope (it's underlying 'engine' so to speak) has a ZWiki 
product.  I haven't used the ZWiki product yet, but it looks good.  I would 
be willing to set up and admin a Plone site.  Drupal or any other CMS I 
would not be willing to invest the time to learn the system enough to admin 
it, but I would be willing to contribute to it. 

> Exactly:
> 1. Decide hosting options.
> 2. Install Drupal.
> 3. Tune Drupal.
> 4. Migrate content.
> 5. Tune Drupal even more, add a bits of design.

With Plone, one consideration is that it doesn't play too nice on a virtual 
private server, a dedicated server is best. 

 --Jason A. Craig

Quoting jacraig@...:

> techtonik writes:
>>
>> No. We need to setup a CMS for it and migrate content (the last thing
>> is the one I could be able to help with). There was a very nice
>> MediaWiki about MinGW somewhere, but the common opinion was to try
>> Drupal. Its new version 5 looks very promising. The problem was that
>> Drupal hadn't had wiki module and we've got a lot of wiki pages.
>>
>
> Is Drupal set in stone?

Absolutely

NOT.

> I've worked on one and built another Plone site

I know this is a templating thing but the Plone.org site makes me run from it.

>
> With Plone, one consideration is that it doesn't play too nice on a virtual
> private server, a dedicated server is best.

Well that leaves it pretty much out in the dark and not a serious 
consideration.  Actually, Joomla.org may be better suited for MinGW but 
I haven't given it any play time.  The JoomlaCode.org GForge interface 
is strikely good.  However, Drupal has its own strikingly good project 
interface that may work just as well.  I may have some time May or June 
to implement a new web interface for MinGW using one of these; I am 
familiar with Drupal but it is all about data->process->data so I am 
open to other possibilities if given proof that it should work well for 
MinGW.

Earnie

Quoting techtonik <techtonik@...>:

>
> The main problem is that we need hosting.

We already have one.

> SF is insecure by design.

Not a concern!  Do you plan to put your secure information on the MinGW 
website.

> I can offer my DreamHost plan, but it is unlikely that my offer will be
> accepted. There were also some talks about SourceWare hosting, so as a
> last resort we can use their facilities.
>

Keith and I have both told you we were not using DreamHost.  If we move 
MinGW it will be somewhere more like GForge which is built on older 
versions of SF code when SF code was Open.

>> Do we simply need to update it?
>
> No. We need to setup a CMS for it and migrate content (the last thing
> is the one I could be able to help with). There was a very nice
> MediaWiki about MinGW somewhere, but the common opinion was to try
> Drupal. Its new version 5 looks very promising. The problem was that
> Drupal hadn't had wiki module and we've got a lot of wiki pages.
>

A wiki is nothing more than a CMS with a specific purpose.  Drupal 
without any additional coding is enough of a wiki to use it for one.  
The choice of CMS will be ease of aggregation with the SF feeds.

>> Are there updates already in the pipeline that simply need to be posted?
>> Do we want it revamped?
>
> Definitely.
>
>> Sorry to bring up the topic again, but depending on what
>> exactly needs to be done I might be willing to lend my efforts to the
>> website.
>
> Exactly:
> 1. Decide hosting options.

The choice is currently SF.

> 2. Install Drupal.

Hopefully to be done by the end of June.

> 3. Tune Drupal.

This includes a template design.  Drupal works best with phptemplate 
but can use smarty; I'm don't know what template engines Joomla 
supports.  If someone wants to design a template for MinGW based on 
phptemplate using Drupal see http://drupal.org/node/509 for 
documentation from the http://drupal.org/handbooks section.

> 4. Migrate content.

Hopefully to be done by the end of June.

> 5. Tune Drupal even more, add a bits of design.
>

Continuously ongoing.

Earnie

Quoting jacraig@...:

> Do we simply need to update it?

If you're willing to update the data then please post patches to the 
patch tracker.

> Are there updates already in the pipeline that simply need to be posted?

There are no patches in the patch tracker against the htdocs code.  The 
only change that hasn't been made to production is the CSS.

> Do we want it revamped?

I've already stated that I hope to revamp by the end of June.

> Sorry to bring up the topic again, but depending on what
> exactly needs to be done I might be willing to lend my efforts to the
> website.
>

The sorriness that needs to be had is in lack of interest; please don't 
apologize for being interested.  You can start by submitting patches to 
the patch tracker.  If you wish access to the htdocs area you will need 
to send me your public ssh key (privately, please).

Earnie

Earnie Boyd writes:
>>
>> I've worked on one and built another Plone site
> 
> I know this is a templating thing but the Plone.org site makes me run from it.

Are you scared of what plone looks like?  Can you guess that 
http://aquamira.com is a plone site? 

> 
>>
>> With Plone, one consideration is that it doesn't play too nice on a virtual
>> private server, a dedicated server is best.
> 
> Well that leaves it pretty much out in the dark and not a serious 
> consideration.

Sorry, let me explain better.  It USUALLY doesn't play well on a virtual 
private server because most virtual private servers don't let you install 
it/use it.  If you have root access along with control over port 
configuration, then you can use Plone. 

 --Jason A. Craig

techtonik wrote:
> On 3/20/07, jacraig@... <jacraig@...> wrote:
>> Do we simply need to update it?
> 
> No. We need to setup a CMS for it and migrate content (...)

Migrating the content without losing any relevant parts is a daunting 
task which requires the full attention of someone who has great amounts 
of time to spare on the task.
The point I wish to make is that the sandbox I created (see below) took 
me a hell of an amount of time for less than 10% of migration.

> There was a very nice MediaWiki about MinGW somewhere, 

Maybe you're talking about the MediaWiki sandbox I had created to 
propose the MediaWiki solution to Earnie.
It's still available here:
http://www.amanitamuscaria.org/MinGWiki/Main_Page

Some relevant (read: almost complete, and pretty nice) pages:
http://www.amanitamuscaria.org/MinGWiki/Packages
http://www.amanitamuscaria.org/MinGWiki/Binutils
(and it's 'building' counter-page)

I'll just point out that MediaWiki had it's pros/cons, resumed partially 
by Earnie:

Earnie Boyd wrote:
> A wiki is nothing more than a CMS with a specific purpose.  Drupal 
> without any additional coding is enough of a wiki to use it for one.  
> The choice of CMS will be ease of aggregation with the SF feeds.

I couldn't agree more; but I believe that if it were possible to 
automate the creation of a wiki page every day from a SF feed, a 
MediaWiki would be at least as good a choice as another CMS such as Drupal.
My judgment is also biased in favor of MediaWiki, since I barely tested 
Drupal.
AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist.

Julien

Quoting jacraig@...:

> Earnie Boyd writes:
>>>
>>> I've worked on one and built another Plone site
>>
>> I know this is a templating thing but the Plone.org site makes me 
>> run from it.
>
> Are you scared of what plone looks like?  Can you guess that
> http://aquamira.com is a plone site?
>

Not too hard to figure out

    <meta name="generator" content="Plone - http://plone.org" />

As I said, ``I know this is a templating thing ...''.  The main 
Plone.org template turns me off.  The site could have used Drupal just 
as easily.

>>
>>>
>>> With Plone, one consideration is that it doesn't play too nice on a virtual
>>> private server, a dedicated server is best.
>>
>> Well that leaves it pretty much out in the dark and not a serious
>> consideration.
>
> Sorry, let me explain better.  It USUALLY doesn't play well on a virtual
> private server because most virtual private servers don't let you install
> it/use it.  If you have root access along with control over port
> configuration, then you can use Plone.
>

No we do not have control of the port nor do we have root access.  I 
have installed Drupal on another SF project.

Earnie

Quoting Julien Lecomte <julien@...>:

> techtonik wrote:
>> On 3/20/07, jacraig@... <jacraig@...> wrote:
>>> Do we simply need to update it?
>>
>> No. We need to setup a CMS for it and migrate content (...)
>
> Migrating the content without losing any relevant parts is a daunting

Currently we have two pieces of content, the main site and the phpwiki 
data.  My main concern at the moment is the main site.

> task which requires the full attention of someone who has great amounts
> of time to spare on the task.
> The point I wish to make is that the sandbox I created (see below) took
> me a hell of an amount of time for less than 10% of migration.
>

If I remember correctly what you had in your sand box included the wiki data.

>> There was a very nice MediaWiki about MinGW somewhere,
>
> Maybe you're talking about the MediaWiki sandbox I had created to
> propose the MediaWiki solution to Earnie.
> It's still available here:
> http://www.amanitamuscaria.org/MinGWiki/Main_Page
>

And the wiki data needs consideration.  The work you did was nicely put 
together.  There are nicities with both MediaWiki and Drupal.

> Some relevant (read: almost complete, and pretty nice) pages:
> http://www.amanitamuscaria.org/MinGWiki/Packages
> http://www.amanitamuscaria.org/MinGWiki/Binutils
> (and it's 'building' counter-page)
>
> I'll just point out that MediaWiki had it's pros/cons, resumed partially
> by Earnie:
>
> Earnie Boyd wrote:
>> A wiki is nothing more than a CMS with a specific purpose.  Drupal
>> without any additional coding is enough of a wiki to use it for one.
>> The choice of CMS will be ease of aggregation with the SF feeds.
>
> I couldn't agree more; but I believe that if it were possible to
> automate the creation of a wiki page every day from a SF feed, a
> MediaWiki would be at least as good a choice as another CMS such as Drupal.

I agree.

> My judgment is also biased in favor of MediaWiki, since I barely tested
> Drupal.

And mine vice versa.

> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist.
>

This might be troublesome.  What you have though may well be suited for 
formatting in Drupal.  I'll have to dig in my email to find a link I 
tried to save where someone templated Drupal to work similar to 
MediaWiki.

Earnie

Earnie Boyd writes:
>
> As I said, ``I know this is a templating thing ...''.  The main 
> Plone.org template turns me off.  The site could have used Drupal just 
> as easily. 
> 
Well I guess the misunderstanding is that I am turned off by people simply 
putting up a CMS without changing it's appearance at all (except maybe the 
logo).  Then you have 5000 clones of Plone or Drupal or WikiMedia, and thus 
your site it boring.  Yes you can do it with a host of different CMS's, and 
yes, it is a template thing.  However, there is no reason in the world to 
keep the default template/appearance/stylesheets that come with your CMS of 
choice. 

My offer was (is) "I am willing to administrate a Plone based overhaul of 
mingw.org.  I am not willing to invest time in learning how to set up and 
customize a different CMS.  I will however contribute to those efforts."  
Take it or leave it. 

 --Jason A. Craig

Earnie Boyd wrote:
> Quoting Julien Lecomte <julien@...>:
> Currently we have two pieces of content, the main site and the phpwiki 
> data.  My main concern at the moment is the main site.

I was thinking about merging both since what is on the main site can be 
in a wiki.

> If I remember correctly what you had in your sand box included the wiki data.
Not much of it actually. I took some pages verbatim or wikified them.

>> I'll just point out that MediaWiki had it's pros/cons. (...)
>> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist.
> This might be troublesome. 

I've just solved the problem of auto-import of the latest releases/news 
from sourceforge.net
A brief reminder of the problem: the blue 'news box' on the main page 
was edited by hand and would require an user to update the page when a 
new release is done.

I've just solved this problem by hacking the mediawiki '<iframe>' 
extension to include via php's 'fopen' 
http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0

http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct 
latest news and releases.

Maybe, after all, MediaWiki might be a good choice.
Julien

On 3/21/07, Earnie Boyd <earnie@...> wrote:

> > The main problem is that we need hosting.
>
> We already have one.
>
> > SF is insecure by design.
>
> Not a concern!  Do you plan to put your secure information on the MinGW
> website.

There was a story with PHP XML-RPC library two years ago that affected
all major open-source PHP products. There were even rumors about
developer's accounts information stolen from Mozilla through this bug.
The guys who maintained this library were warned like you, but there
too stubborn to separate emotions from rationale. Do you want that
story to be repeated?

If you do not trust me then point any database driven project on
SourceForge to see your name on its main page.

> > I can offer my DreamHost plan, but it is unlikely that my offer will be
> > accepted. There were also some talks about SourceWare hosting, so as a
> > last resort we can use their facilities.
> >
>
> Keith and I have both told you we were not using DreamHost.  If we move
> MinGW it will be somewhere more like GForge which is built on older
> versions of SF code when SF code was Open.

I know you've told me - that's why I am telling it to others. As for
SF interface I do not think it rocks. In addition I always thought
that GForge is slow. There are many superior project management
interfaces like Trac.

> A wiki is nothing more than a CMS with a specific purpose.  Drupal
> without any additional coding is enough of a wiki to use it for one.
> The choice of CMS will be ease of aggregation with the SF feeds.

Aggregation is the most easy part  for any framework if information
supplied in RSS or any other well-described format. Even for MediaWiki
if you give me a skeleton plugin to do by example.

But here is one limitation of SF I almost forgot about - SF doesn't
allow outgoing connections. So there are good chances that you won't
be able to import desired content at all.


> > Exactly:
> > 1. Decide hosting options.
>
> The choice is currently SF.
>
> > 2. Install Drupal.
>
> Hopefully to be done by the end of June.
>
> > 3. Tune Drupal.
>
> This includes a template design.  Drupal works best with phptemplate
> but can use smarty; I'm don't know what template engines Joomla
> supports.  If someone wants to design a template for MinGW based on
> phptemplate using Drupal see http://drupal.org/node/509 for
> documentation from the http://drupal.org/handbooks section.

At least provide plain 800x600 image of design.


As for Plone - I really like the idea of designing something over a
top of application server - it can greatly reduce the amount of time
wasted, but running appserver such as Zope indeed requires more
resources than a typical shared hosting can provide for non-commercial
project.

-- 
--anatoly t.

Earnie Boyd writes: 

>> 3. Tune Drupal.
> 
> This includes a template design.  Drupal works best with phptemplate 
> but can use smarty; I'm don't know what template engines Joomla 
> supports.  If someone wants to design a template for MinGW based on 
> phptemplate using Drupal see http://drupal.org/node/509 for 
> documentation from the http://drupal.org/handbooks section.

Well since Drupal is the choice, perhaps I will get started on templates.  
Are there any requirements for the design?  Is there a pre-existing comp for 
a design?  Should the design be like the current site? 

 --Jason A. Craig

Quoting jacraig@...:

> Earnie Boyd writes:
>
>>> 3. Tune Drupal.
>>
>> This includes a template design.  Drupal works best with phptemplate
>> but can use smarty; I'm don't know what template engines Joomla
>> supports.  If someone wants to design a template for MinGW based on
>> phptemplate using Drupal see http://drupal.org/node/509 for
>> documentation from the http://drupal.org/handbooks section.
>
> Well since Drupal is the choice, perhaps I will get started on templates.
> Are there any requirements for the design?  Is there a pre-existing comp for
> a design?  Should the design be like the current site?
>

The design of the site we have now is simplistic because I DNKWIWD.  I 
do not care if you apply some artistic ability to the template.  The 
main goal is ease of navigation and interaction between SF and any 
other third party package we may interoperate with.  There are modules 
that allow a different template for different pages and/or functions.  
In Drupal core with version 5.0 and above you can apply a separate 
template for administration UI than for the site UI.  We could even 
enable more than one template and let the authenticated visitor choose 
which template she desires.

Earnie

Quoting techtonik <techtonik@...>:

>
> If you do not trust me then point any database driven project on
> SourceForge to see your name on its main page.
>

http://www.google.com/search?hl=en&q=techtonik&btnG=Google+Search

You see, I am not concerned with my name being used by others because I 
used the SF site.  I do not store personally liable information on a 
public interface.  It has nothing to do with trusting you, it has to do 
with trusting that 100s of 1000s of projects are using SF for its 
infrastructure.  It is therefore not a concern.

Earnie

Quoting Julien Lecomte <julien@...>:

> Earnie Boyd wrote:
>> Quoting Julien Lecomte <julien@...>:
>> Currently we have two pieces of content, the main site and the phpwiki
>> data.  My main concern at the moment is the main site.
>
> I was thinking about merging both since what is on the main site can be
> in a wiki.
>

Eventually over a length of time, maybe.

>> If I remember correctly what you had in your sand box included the 
>> wiki data.
> Not much of it actually. I took some pages verbatim or wikified them.
>
>>> I'll just point out that MediaWiki had it's pros/cons. (...)
>>> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist.
>> This might be troublesome.
>
> I've just solved the problem of auto-import of the latest releases/news
> from sourceforge.net
> A brief reminder of the problem: the blue 'news box' on the main page
> was edited by hand and would require an user to update the page when a
> new release is done.
>
> I've just solved this problem by hacking the mediawiki '<iframe>'
> extension to include via php's 'fopen'
> http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
>

Is this screen scrape method so that if SF changes its HTML UI you 
would need to change the data pieces?  Not interested in that.  You 
could use the RSS feed and use the XML data.  Yes I know SF can change 
the layout of the XML.

> http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct
> latest news and releases.
>
> Maybe, after all, MediaWiki might be a good choice.

I will admit that your three column template looks good.  It is too bad 
that there isn't more control on the template overall.  We can offer 
the user a choice of template to view the data with Drupal.  In my 
opinion a wiki look for the front landing page cheapens the impression 
of a project unless you're actually the one producing the wiki or your 
name is wikipedia.

Earnie

Earnie Boyd writes:
>> Earnie Boyd wrote:
> 
> Is this screen scrape method so that if SF changes its HTML UI you 
> would need to change the data pieces?  Not interested in that.  You 
> could use the RSS feed and use the XML data.  Yes I know SF can change 
> the layout of the XML. 
> 

Agreed.  It would be fairly easy to create an XSLT stylesheet and simply 
transform the RSS data into inline HTML with PHP, so it shouldn't too hard 
to get a fairly maintainable method of displaying live sourceforge data.  
I've done this before in PHP. 

> In my 
> opinion a wiki look for the front landing page cheapens the impression 
> of a project unless you're actually the one producing the wiki or your 
> name is wikipedia. 
> 

Agree 100%. 

 --Jason A. Craig

Earnie Boyd wrote:
> Quoting Julien Lecomte <julien@...>:
>> Earnie Boyd wrote:
>>> Quoting Julien Lecomte <julien@...>:
>>> Currently we have two pieces of content, the main site and the phpwiki
>>> data.  My main concern at the moment is the main site.
>> I was thinking about merging both since what is on the main site can be
>> in a wiki.
> Eventually over a length of time, maybe.

The data on the main site is the easiest to replicate, there's more work 
to be done when replicating the phpwiki.

>>>> I'll just point out that MediaWiki had it's pros/cons. (...)
>>>> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist.
>>> This might be troublesome.
>> I've just solved the problem of auto-import of the latest releases/news
>> from sourceforge.net
>> A brief reminder of the problem: the blue 'news box' on the main page
>> was edited by hand and would require an user to update the page when a
>> new release is done.
>>
>> I've just solved this problem by hacking the mediawiki '<iframe>'
>> extension to include via php's 'fopen'
>> http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
> 
> Is this screen scrape method so that if SF changes its HTML UI you 
> would need to change the data pieces?  Not interested in that.  You 
> could use the RSS feed and use the XML data.  Yes I know SF can change 
> the layout of the XML.

I just download the page and include it verbatim since my host allows 
cross-site http inclusion which is by default unsafe and probably 
disallowed on SF.
On SF I was thinking we could fcron a wget on the url, and then include 
the local copy of it; much simpler than 'news-update.sh' on the shell 
server.

We could parse a RSS or an XML feed and create a page for inclusion if 
we wish to. It would, in any case, work just like it currently works on 
mingw.org.

In any case, if SF wishes to change something, they'll change it without 
telling us before hand, and change it to something that breaks the most 
things possible.

>> http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct
>> latest news and releases.
>>
>> Maybe, after all, MediaWiki might be a good choice.
> 
> I will admit that your three column template looks good.

The credit really goes out to gpwiki.org.

> It is too bad 
> that there isn't more control on the template overall.  We can offer
> the user a choice of template to view the data with Drupal.  In my 
> opinion a wiki look for the front landing page cheapens the impression 
> of a project unless you're actually the one producing the wiki or your 
> name is wikipedia.

Some talented users have created skins for their own projects. Some of 
these projects don't look at all like a Wikipedia.
Some examples are listed on this page:
http://meta.wikimedia.org/wiki/Gallery_of_user_styles

I've tried your DNKWIWD method to try to make a skin for the MinGWiki 
sandbox. It "kinda" looks like http://www.mingw.org now (but with some css bugs)
Julien

On 3/21/07, Julien Lecomte <julien@...> wrote:

> >> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist.
> > This might be troublesome.
>
> I've just solved the problem of auto-import of the latest releases/news
> from sourceforge.net

I should have read this mail before hacking into MediaWiki. =)

> I've just solved this problem by hacking the mediawiki '<iframe>'
> extension to include via php's 'fopen'
> http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
>
> http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct
> latest news and releases.
>

Does that mean every time you access the main page a request to SF is made?
Do you cache it?

This seems to be a better way to get the contents from SF in current
form. My extension is more complex - it is a rip-off from another news
aggregator of mine stripped down to handle only SF feeds. That's why
extra database and synchronization layers.

-- 
--anatoly t.

On 3/22/07, Earnie Boyd <earnie@...> wrote:

> > If you do not trust me then point any database driven project on
> > SourceForge to see your name on its main page.
> >

> I do not store personally liable information on a
> public interface.  It has nothing to do with trusting you, it has to do
> with trusting that 100s of 1000s of projects are using SF for its
> infrastructure.  It is therefore not a concern.

I see. You do not care if somebody stoles information about MinGW
users including email addresses and passwords hashes. But how about
changing their passwords and acting from your name, injecting
malicious code into MinGW site content without any history traces? Do
you care?

-- 
--anatoly t.

> >
> > I've just solved this problem by hacking the mediawiki '<iframe>'
> > extension to include via php's 'fopen'
> > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
> >
>
> Is this screen scrape method so that if SF changes its HTML UI you
> would need to change the data pieces?  Not interested in that.  You
> could use the RSS feed and use the XML data.  Yes I know SF can change
> the layout of the XML.

If SF changes anything there will be a mess in either case. This is an
official HTML export interface and SF is aware of the fact that it is
should not be broken, because many rely on its current format.

> > http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct
> > latest news and releases.
> >
> > Maybe, after all, MediaWiki might be a good choice.
>
> I will admit that your three column template looks good.  It is too bad
> that there isn't more control on the template overall.  We can offer
> the user a choice of template to view the data with Drupal.  In my
> opinion a wiki look for the front landing page cheapens the impression
> of a project unless you're actually the one producing the wiki or your
> name is wikipedia.

Any default template cheapens the impression of the project be it
Drupal or MediaWiki. I am not afraid to repeat that so far (IMHO) even
the default cheap look of WikiMedia is much more pleasant than current
mingw.org "design". Tuned WikiMedia will be just great.

-- 
--anatoly t.

techtonik writes: 

>> >
>> > I've just solved this problem by hacking the mediawiki '<iframe>'
>> > extension to include via php's 'fopen'
>> > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
>> > 
>>
>> Is this screen scrape method so that if SF changes its HTML UI you
>> would need to change the data pieces?  Not interested in that.  You
>> could use the RSS feed and use the XML data.  Yes I know SF can change
>> the layout of the XML.
> 
> If SF changes anything there will be a mess in either case. This is an
> official HTML export interface and SF is aware of the fact that it is
> should not be broken, because many rely on its current format. 
> 

I've created an XSL stylesheet that will transform the RSS data into the 
current format of title, date, and link.  If (when) Drupal is implemented, 
the "news" or "releases" area can use PHP's XML and XSL functions to 
transform the feed and it will then be styled by the CSS stylesheets in 
place for the site.  The only way that this can break is if Sourceforge 
changes the location of the RSS feed, or breaks from the RSS specification 
and publishes the feeds in a different format. 

I've also installed a copy of Drupal locally and I've begun to create a 
proposal for a PHPTemplate skin or theme for the MinGW site.  I implemented 
a live feed of the project news in the template. 

 --Jason A. Craig

On 3/25/07, jacraig@... <jacraig@...> wrote:
> >
> > If SF changes anything there will be a mess in either case. This is an
> > official HTML export interface and SF is aware of the fact that it is
> > should not be broken, because many rely on its current format.
> >
>
> I've created an XSL stylesheet that will transform the RSS data into the
> current format of title, date, and link.  If (when) Drupal is implemented,
> the "news" or "releases" area can use PHP's XML and XSL functions to
> transform the feed and it will then be styled by the CSS stylesheets in
> place for the site.  The only way that this can break is if Sourceforge
> changes the location of the RSS feed, or breaks from the RSS specification
> and publishes the feeds in a different format.

I do not think that happens. In any case it is not a problem to
convert RSS to Atom and vice versa.

> I've also installed a copy of Drupal locally and I've begun to create a
> proposal for a PHPTemplate skin or theme for the MinGW site.  I implemented
> a live feed of the project news in the template.

Good! I am still interested to see how it works. I still have no idea
how to update Drupal or import information from wiki.

-- 
--anatoly t.

On 24/03/2007 13:52, techtonik wrote:
> On 3/21/07, Julien Lecomte <julien@...> wrote:
> 
>> I've just solved the problem of auto-import of the latest releases/news
>> from sourceforge.net
> 
>> I've just solved this problem by hacking the mediawiki '<iframe>'
>> extension to include via php's 'fopen'
>> http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
>>
>> http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct
>> latest news and releases.
> 
> Does that mean every time you access the main page a request to SF is
> made?

Yes

> Do you cache it?

No

That page is sandbox, a test/sample website for my proposal. I don't 
care for performance since it's not meant for production.

> This seems to be a better way to get the contents from SF in current
> form. My extension is more complex - it is a rip-off from another news
> aggregator of mine stripped down to handle only SF feeds. That's why
> extra database and synchronization layers.

I've looked at it, and it's overkill. My current plugin is less than 5 
lines in php, doesn't require DB changes or connection, etc...
You also gave just sourcecode, no example, no sample website to show 
that it works.

My current sandbox method will not work as-is on SF because of SF 
limitation my current host does not enforce. This limitation will also 
block your script:
On SF, we'll have to use the current cron/wget method which means that 
the page will only be downloaded every hour (cache problem solved.)

Julien

Quoting jacraig@...:

> techtonik writes:
>
>>> >
>>> > I've just solved this problem by hacking the mediawiki '<iframe>'
>>> > extension to include via php's 'fopen'
>>> > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0
>>> >
>>>
>>> Is this screen scrape method so that if SF changes its HTML UI you
>>> would need to change the data pieces?  Not interested in that.  You
>>> could use the RSS feed and use the XML data.  Yes I know SF can change
>>> the layout of the XML.
>>
>> If SF changes anything there will be a mess in either case. This is an
>> official HTML export interface and SF is aware of the fact that it is
>> should not be broken, because many rely on its current format.
>>
>
> I've created an XSL stylesheet that will transform the RSS data into the
> current format of title, date, and link.  If (when) Drupal is implemented,
> the "news" or "releases" area can use PHP's XML and XSL functions to
> transform the feed and it will then be styled by the CSS stylesheets in
> place for the site.  The only way that this can break is if Sourceforge
> changes the location of the RSS feed, or breaks from the RSS specification
> and publishes the feeds in a different format.
>

Cool stuff.  Thanks for the work on this.

> I've also installed a copy of Drupal locally and I've begun to create a
> proposal for a PHPTemplate skin or theme for the MinGW site.  I implemented
> a live feed of the project news in the template.
>

This will be good stuff.  Which version of Drupal?

Earnie

Quoting techtonik <techtonik@...>:

> On 3/22/07, Earnie Boyd <earnie@...> wrote:
>
>> > If you do not trust me then point any database driven project on
>> > SourceForge to see your name on its main page.
>> >
>
>> I do not store personally liable information on a
>> public interface.  It has nothing to do with trusting you, it has to do
>> with trusting that 100s of 1000s of projects are using SF for its
>> infrastructure.  It is therefore not a concern.
>
> I see. You do not care if somebody stoles information about MinGW
> users including email addresses and passwords hashes. But how about
> changing their passwords and acting from your name, injecting
> malicious code into MinGW site content without any history traces? Do
> you care?
>

Drupal maintainers go out of their way to try to stop this hackery.  
Forwarding something to a SF user email address is as simple as knowing 
the SF user name.  With Drupal, inserting code into text areas requires 
permission.  It isn't that I don't care, it is more that I am not 
concerned.  I often use one set of passwords to register for an account 
and will later change it to another password once the registration is 
complete.  With Drupal, the user is sent a generated password that can 
be changed by the user on initial or later logon.  The ``forgot 
password'' function will generate a new password and email the user.

Earnie

On 3/25/07, Julien Lecomte <julien@...> wrote:
>
> > This seems to be a better way to get the contents from SF in current
> > form. My extension is more complex - it is a rip-off from another news
> > aggregator of mine stripped down to handle only SF feeds. That's why
> > extra database and synchronization layers.
>
> I've looked at it, and it's overkill. My current plugin is less than 5
> lines in php, doesn't require DB changes or connection, etc...
> You also gave just sourcecode, no example, no sample website to show
> that it works.

I doubt this list archives are not exposed to internet and I really do
not want any spam bots to spam this test wiki, so a little
inconvenience here.

http://wiki + rainforce + org/index.php?title=Special:SourceForgeNews


> My current sandbox method will not work as-is on SF because of SF
> limitation my current host does not enforce. This limitation will also
> block your script:
> On SF, we'll have to use the current cron/wget method which means that
> the page will only be downloaded every hour (cache problem solved.)

SF doesn't allow outgoing connections even for its own site if I am
not mistaken. It is easy to check though. Cron job were also turned
off last time I checked them some months ago. So I've setup an
external aggregator, which is triggered by users via an image linked
to external site. News are then fed through XML-RPC interface. This
technique is used in farplugins project here, on SF.

-- 
--anatoly t.

Earnie Boyd writes:
>> I've also installed a copy of Drupal locally and I've begun to create a
>> proposal for a PHPTemplate skin or theme for the MinGW site.  I implemented
>> a live feed of the project news in the template. 
>>
> 
> This will be good stuff.  Which version of Drupal? 
> 

5.1 - is this OK?  When I get a little more done on a template I will figure 
out where to stick it and get it up online so people can see. 

 --Jason A. Craig

Quoting jacraig@...:

> Earnie Boyd writes:
>>> I've also installed a copy of Drupal locally and I've begun to create a
>>> proposal for a PHPTemplate skin or theme for the MinGW site.  I implemented
>>> a live feed of the project news in the template.
>>>
>>
>> This will be good stuff.  Which version of Drupal?
>>
>
> 5.1 - is this OK?  When I get a little more done on a template I will figure
> out where to stick it and get it up online so people can see.
>

5.1 should be OK.  We already have a place to stick it.  We could 
prefix the DB tables with ``dev_'' and install into the test area we 
already have operational.

Earnie

Quoting techtonik <techtonik@...>:

> On 3/25/07, Earnie Boyd <earnie@...> wrote:
>> Quoting techtonik <techtonik@...>:
>> >
>> > I see. You do not care if somebody stoles information about MinGW
>> > users including email addresses and passwords hashes. But how about
>> > changing their passwords and acting from your name, injecting
>> > malicious code into MinGW site content without any history traces? Do
>> > you care?
>> >
>>
>> Drupal maintainers go out of their way to try to stop this hackery.
>> Forwarding something to a SF user email address is as simple as knowing
>> the SF user name.  With Drupal, inserting code into text areas requires
>> permission.  It isn't that I don't care, it is more that I am not
>> concerned.
>
> So you think it is not important. Ok. Let me skip the rest of the post
> about passwords. If you make changes directly to Drupal database you
> do not need any permissions or user passwords and that is the reason
> with SourceForge. I hope now it is clear.
>

And should someone actually manage to modify the password of an account 
via MySql, what is it he might do with the account?  Post an article?  
If he gets that far, why not just drop the tables?  I am not concerned 
that someone with crackery skills is going to be using my DB to SPAM me 
or others.  That security issue belongs to SF.  I would suggest to 
anyone applying for a MinGW Drupal account that they use they're SF 
forwarding address; e.g. foo@....  As I said already, 
it is easy to SPAM an SF user.

Earnie

On 3/26/07, Earnie Boyd <earnie@...> wrote:
> Quoting techtonik <techtonik@...>:
>
> > On 3/25/07, Earnie Boyd <earnie@...> wrote:
> >> Quoting techtonik <techtonik@...>:
> >> >
> >> > I see. You do not care if somebody stoles information about MinGW
> >> > users including email addresses and passwords hashes. But how about
> >> > changing their passwords and acting from your name, injecting
> >> > malicious code into MinGW site content without any history traces? Do
> >> > you care?
> >> >
> >>
> >> Drupal maintainers go out of their way to try to stop this hackery.
> >> Forwarding something to a SF user email address is as simple as knowing
> >> the SF user name.  With Drupal, inserting code into text areas requires
> >> permission.  It isn't that I don't care, it is more that I am not
> >> concerned.
> >
> > So you think it is not important. Ok. Let me skip the rest of the post
> > about passwords. If you make changes directly to Drupal database you
> > do not need any permissions or user passwords and that is the reason
> > with SourceForge. I hope now it is clear.
> >
>
> And should someone actually manage to modify the password of an account
> via MySql, what is it he might do with the account?  Post an article?

Post a fresh exploit for your dear browser.

> If he gets that far, why not just drop the tables?

Because bot-nets are more profitable than tabledrops.

> I am not concerned
> that someone with crackery skills is going to be using my DB to SPAM me
> or others.  That security issue belongs to SF.  I would suggest to
> anyone applying for a MinGW Drupal account that they use they're SF
> forwarding address; e.g. foo@....

Am I right that you want to limit editing activities to only a few
users with explicit permission from you side? =) May I make an
assumption that you risk to end up with lots of confusing and stale
content unless you'll be doing the edits yourself?

-- 
--anatoly t.

techtonik writes:
> 
> Am I right that you want to limit editing activities to only a few
> users with explicit permission from you side? =) May I make an
> assumption that you risk to end up with lots of confusing and stale
> content unless you'll be doing the edits yourself?

Certain parts of the site, like most of it, do not lend themselves to be 
edited by the general public.  A few people, (say, developers on the mingw 
project??) could have access to these pages.  It makes more sense for an 
area like the Wiki pages to be able to be editable by the general public 
(registered users of the MinGW.org site). 

 --Jason A. Craig

Quoting techtonik <techtonik@...>:

>
> Am I right that you want to limit editing activities to only a few
> users with explicit permission from you side? =) May I make an
> assumption that you risk to end up with lots of confusing and stale
> content unless you'll be doing the edits yourself?
>

Roles and rules can be set to allow and disallow access to ``node 
types'' and to the site itself.  So I can have a node type for creating 
site pages only editable by a specific role.  I can create a node type 
that is more wiki oriented that allows any authenticated user to edit a 
wiki node type.  Comments can be allowed or disallowed for each node 
type and can require authentication or not.  The site pages should be 
minimal to help eliminate the staleness of the site and would not be 
promoted to the front page.  Stories of the successful use of MinGW can 
be allowed to be posted for the front page as well as possibly the 
lastest wiki node type entry.

Earnie

On 3/26/07, Earnie Boyd <earnie@...> wrote:

> Roles and rules can be set to allow and disallow access to ``node
> types'' and to the site itself.  So I can have a node type for creating
> site pages only editable by a specific role.  I can create a node type
> that is more wiki oriented that allows any authenticated user to edit a
> wiki node type.  Comments can be allowed or disallowed for each node
> type and can require authentication or not.  The site pages should be
> minimal to help eliminate the staleness of the site and would not be
> promoted to the front page.  Stories of the successful use of MinGW can
> be allowed to be posted for the front page as well as possibly the
> lastest wiki node type entry.

Ok. That's a good vision. So, what about hosting? Don't you mind
unathorized third-party folks messing with MinGW database? Me
personally would not agree to support so insecurely backed up site
even considering MinGW doesn't have any distinct enemies around right
now.

Just curious if there is another opinion than "we don't have choice".

-- 
--anatoly t.

techtonik writes: 

> Ok. That's a good vision. So, what about hosting? Don't you mind
> unathorized third-party folks messing with MinGW database? Me
> personally would not agree to support so insecurely backed up site
> even considering MinGW doesn't have any distinct enemies around right
> now. 
> 

I'm sorry, maybe I missed it, but what exactly is the problem? 

 --Jason

On 3/27/07, jacraig@... <jacraig@...> wrote:
> techtonik writes:
>
> > Ok. That's a good vision. So, what about hosting? Don't you mind
> > unathorized third-party folks messing with MinGW database? Me
> > personally would not agree to support so insecurely backed up site
> > even considering MinGW doesn't have any distinct enemies around right
> > now.
> >
>
> I'm sorry, maybe I missed it, but what exactly is the problem?
>

The problem is that SF hosting is not for heavy database driven sites
and they are not going to make it any more secure. Using brains and SF
account anybody can easily alter your database, inject content, do
other nasty things creating problems unnoticed. I proposed Earnie to
name any DB driven site on SF to prove the concept, but Earnie
refused, so I conclude that Earnie is aware of the fact.

-- 
--anatoly t.

techtonik writes: 

> The problem is that SF hosting is not for heavy database driven sites
> and they are not going to make it any more secure. Using brains and SF
> account anybody can easily alter your database, inject content, do
> other nasty things creating problems unnoticed. I proposed Earnie to
> name any DB driven site on SF to prove the concept, but Earnie
> refused, so I conclude that Earnie is aware of the fact.

What does your host have to do with the security of YOUR database?  Do users 
of other SF sites get logins to your database?  Do they allow people to get 
access to your hosted files with their SF account?  If so then I can see the 
security hole, if not...if you administer your own site and database 
correctly then it will be secure. 

 --Jason A. Craig

On 3/27/07, jacraig@... <jacraig@...> wrote:
>
> What does your host have to do with the security of YOUR database?  Do users
> of other SF sites get logins to your database?

Not automatically, but yes - they can.

> Do they allow people to get
> access to your hosted files with their SF account?

Yes, in readonly mode.

> If so then I can see the
> security hole, if not...if you administer your own site and database
> correctly then it will be secure.

You are mistaken.

-- 
--anatoly t.

Quoting techtonik <techtonik@...>:

>
> The problem is that SF hosting is not for heavy database driven sites
> and they are not going to make it any more secure. Using brains and SF
> account anybody can easily alter your database, inject content, do
> other nasty things creating problems unnoticed. I proposed Earnie to
> name any DB driven site on SF to prove the concept, but Earnie
> refused, so I conclude that Earnie is aware of the fact.
>

Other users with shell access can read other projects htdocs directory 
given the default permissions.  Given that the typical configuration 
files of most MySql projects have a readable password which is usually 
an administrative one.  So, if someone can read the file it doesn't 
take long for crackery to become available.

I wish that every MySql project stored the password in cypherable hash 
to make it more difficult to decern but they don't.  Given this I would 
wage that crakers could quickly decern most MySql administrative 
passwords regardless of the host.  As I said we will caution on 
registration page of the dangers but those dangers are really prevalent 
throughout SF.  We can set the db config file so that it is only 
readable by httpd to make it tougher.  Backups can save the data in the 
event of catastrophe but someone needs to be responsible enough to do 
that.

Earnie

Quoting techtonik <techtonik@...>:

> On 3/26/07, Earnie Boyd <earnie@...> wrote:
>
>> Roles and rules can be set to allow and disallow access to ``node
>> types'' and to the site itself.  So I can have a node type for creating
>> site pages only editable by a specific role.  I can create a node type
>> that is more wiki oriented that allows any authenticated user to edit a
>> wiki node type.  Comments can be allowed or disallowed for each node
>> type and can require authentication or not.  The site pages should be
>> minimal to help eliminate the staleness of the site and would not be
>> promoted to the front page.  Stories of the successful use of MinGW can
>> be allowed to be posted for the front page as well as possibly the
>> lastest wiki node type entry.
>
> Ok. That's a good vision. So, what about hosting? Don't you mind
> unathorized third-party folks messing with MinGW database? Me
> personally would not agree to support so insecurely backed up site
> even considering MinGW doesn't have any distinct enemies around right
> now.
>

Correct, I am not concerned.  Backup is a good choice for protection 
from disaster.  The type of data entered for the web site isn't 
critical (i.e. containing sensitive information) so I am not concerned. 
  If you're afraid of SPAM then stop using email.

> Just curious if there is another opinion than "we don't have choice".
>

Good question.  I didn't note any responses to it.

Earnie

On 3/28/07, Earnie Boyd <earnie@...> wrote:

> Other users with shell access can read other projects htdocs directory
> given the default permissions.  Given that the typical configuration
> files of most MySql projects have a readable password which is usually
> an administrative one.  So, if someone can read the file it doesn't
> take long for crackery to become available.

Nice to hear that.

> I wish that every MySql project stored the password in cypherable hash
> to make it more difficult to decern but they don't.

It is impossible to store hash as you need to supply password to MySQL
in its original form.

> Given this I would
> wage that crakers could quickly decern most MySql administrative
> passwords regardless of the host.

Let it be clear - it's the problem of SF hosts only.

> As I said we will caution on
> registration page of the dangers but those dangers are really prevalent
> throughout SF.

That's why people are moving their web sites pages out of SF. It also
could be the policy of SF itself to reduce the load on its servers by
forcing those who care about security use other hosting services for
heavy database driven site software.

> We can set the db config file so that it is only
> readable by httpd to make it tougher.

AFAIR httpd is not in any of your groups, so the only choice to make
it read your files it to make them readable by everyone.

> Backups can save the data in the
> event of catastrophe but someone needs to be responsible enough to do
> that.

-- 
--anatoly t.

techtonik writes:
> Ok. That's a good vision. So, what about hosting? Don't you mind
> unathorized third-party folks messing with MinGW database? Me
> personally would not agree to support so insecurely backed up site
> even considering MinGW doesn't have any distinct enemies around right
> now. 
> 
> Just curious if there is another opinion than "we don't have choice".

OK, so assuming "as far as you know" the sf sites are so hackable, what 
exactly is the problem?  If somebody wanted to change the content on our 
site, why wouldn't they just sign up with our site and change it?  Sorry 
that you have to hear this, but the nature of Wiki is that the general 
public can change stuff.  Sometimes you will get a bad apple that will 
change stuff in a bad way.  You just have to remove those changes and move 
on.  Earnie's "vision" is not only spot on, but easy to implement, and will 
keep the core of the site stable (assuming noone hacks sf, also assuming we 
don't let someone that hates us sign up as a site developer) while allowing 
excellent organic change on the Wiki pages. 

 --Jason A. Craig

Quoting techtonik <techtonik@...>:

>
>> I wish that every MySql project stored the password in cypherable hash
>> to make it more difficult to decern but they don't.
>
> It is impossible to store hash as you need to supply password to MySQL
> in its original form.
>

I said cypherable hash, meaning the hash can be decrypted by some 
algorithm.  It just slows down the crackery, doesn't prevent it but 
makes it not easy.

>> Given this I would
>> wage that crakers could quickly decern most MySql administrative
>> passwords regardless of the host.
>
> Let it be clear - it's the problem of SF hosts only.
>

So say you.

>> As I said we will caution on
>> registration page of the dangers but those dangers are really prevalent
>> throughout SF.
>
> That's why people are moving their web sites pages out of SF. It also
> could be the policy of SF itself to reduce the load on its servers by
> forcing those who care about security use other hosting services for
> heavy database driven site software.
>

If we had the need to concern ourselves with the data stored, it would 
be plausible to look elsewhere.

>> We can set the db config file so that it is only
>> readable by httpd to make it tougher.
>
> AFAIR httpd is not in any of your groups, so the only choice to make
> it read your files it to make them readable by everyone.
>

I've made the file read/write only by httpd before on SF; I believe I 
can still do that.

Earnie

On 3/28/07, jacraig@... <jacraig@...> wrote:
> techtonik writes:
> > Ok. That's a good vision. So, what about hosting? Don't you mind
> > unathorized third-party folks messing with MinGW database? Me
> > personally would not agree to support so insecurely backed up site
> > even considering MinGW doesn't have any distinct enemies around right
> > now.
> >
> > Just curious if there is another opinion than "we don't have choice".
>
> OK, so assuming "as far as you know" the sf sites are so hackable, what
> exactly is the problem?  If somebody wanted to change the content on our
> site, why wouldn't they just sign up with our site and change it?  Sorry
> that you have to hear this, but the nature of Wiki is that the general
> public can change stuff.

It is indeed funny to hear "sorry". =) The problem that wiki engine
employs customized markup that prevents general public to change stuff
into JavaScripts and other "friendly" user-content. JFY -
http://en.wikipedia.org/wiki/XSS

You may start right from with exploit scenarios.

> Sometimes you will get a bad apple that will
> change stuff in a bad way.  You just have to remove those changes and move
> on.

Sometimes it is impossible to notice rotten part when it is hidden
from your view. Moreover you can munch a worm from a piece of good
apple if you are not cautious enough.

-- 
--anatoly t.

On 3/29/07, Earnie Boyd <earnie@...> wrote:
> >
> >> I wish that every MySql project stored the password in cypherable hash
> >> to make it more difficult to decern but they don't.
> >
> > It is impossible to store hash as you need to supply password to MySQL
> > in its original form.
>
> I said cypherable hash, meaning the hash can be decrypted by some
> algorithm.  It just slows down the crackery, doesn't prevent it but
> makes it not easy.

Very interesting theory. May you point any practical examples how to
crypt and decrypt passwords in PHP scripts in this way before sending
them to MySQL?

> >> Given this I would
> >> wage that crakers could quickly decern most MySql administrative
> >> passwords regardless of the host.
> >
> > Let it be clear - it's the problem of SF hosts only.
> >
> So say you.

Do you have another argument? An example of different host with the
same problems?

> >> We can set the db config file so that it is only
> >> readable by httpd to make it tougher.
> >
> > AFAIR httpd is not in any of your groups, so the only choice to make
> > it read your files it to make them readable by everyone.
> >
>
> I've made the file read/write only by httpd before on SF; I believe I
> can still do that.

Still if apache can read the file - any PHP script will do.
I've just failed to give up ownership and/or group to nfsnobody. Could
you check if this is possible?

-- 
--anatoly t.

Quoting techtonik <techtonik@...>:

> On 3/29/07, Earnie Boyd <earnie@...> wrote: (edited)
>> >
>> >> I wish that every MySql project stored the password in cipherable hash
>> >> to make it more difficult to decern but they don't.
>> >
>> > It is impossible to store hash as you need to supply password to MySQL
>> > in its original form.
>>
>> I said cipherable hash, meaning the hash can be decrypted by some
>> algorithm.  It just slows down the crackery, doesn't prevent it but
>> makes it not easy.
>
> Very interesting theory. May you point any practical examples how to
> crypt and decrypt passwords in PHP scripts in this way before sending
> them to MySQL?
>

http://www.developertutorials.com/tutorials/php/reversible-encryption-routine-php-050415/page11.html

I've used techniques like this one.  Sorry, can't share the specifics.

Earnie

Quoting techtonik <techtonik@...>:

> On 3/28/07, jacraig@... <jacraig@...> wrote:
>> techtonik writes:
>> > Ok. That's a good vision. So, what about hosting? Don't you mind
>> > unathorized third-party folks messing with MinGW database? Me
>> > personally would not agree to support so insecurely backed up site
>> > even considering MinGW doesn't have any distinct enemies around right
>> > now.
>> >
>> > Just curious if there is another opinion than "we don't have choice".
>>
>> OK, so assuming "as far as you know" the sf sites are so hackable, what
>> exactly is the problem?  If somebody wanted to change the content on our
>> site, why wouldn't they just sign up with our site and change it?  Sorry
>> that you have to hear this, but the nature of Wiki is that the general
>> public can change stuff.
>
> It is indeed funny to hear "sorry". =) The problem that wiki engine
> employs customized markup that prevents general public to change stuff
> into JavaScripts and other "friendly" user-content. JFY -
> http://en.wikipedia.org/wiki/XSS
>
> You may start right from with exploit scenarios.
>

I have already stated that the developers of Drupal go out of their way 
to eliminate XSS exploits.  They are allowed only if the administrator 
is stupid.  Only filter specified html tags are allowed to be rendered 
and the rest are either ignored or rendered as the string via encoding 
it.  If an exploit is found a release is soon to follow.

Earnie

On 3/29/07, Earnie Boyd <earnie@...> wrote:

> >> >
> >> >> I wish that every MySql project stored the password in cipherable hash
> >> >> to make it more difficult to decern but they don't.
> >> >
> >> > It is impossible to store hash as you need to supply password to MySQL
> >> > in its original form.
> >>
> >> I said cipherable hash, meaning the hash can be decrypted by some
> >> algorithm.  It just slows down the crackery, doesn't prevent it but
> >> makes it not easy.
> >
> > Very interesting theory. May you point any practical examples how to
> > crypt and decrypt passwords in PHP scripts in this way before sending
> > them to MySQL?
> >
>
> http://www.developertutorials.com/tutorials/php/reversible-encryption-routine-php-050415/page11.html
>
> I've used techniques like this one.  Sorry, can't share the specifics.
>

Even if this could be effective for some skript-kiddies who just
followed the instruction it will not stop anyone who stepped so far to
gain the access to these files himself from copy-pasting the routine
to its own script to decode the "hash".

-- 
--anatoly t.

techtonik writes:
> 
> Sometimes it is impossible to notice rotten part when it is hidden
> from your view. Moreover you can munch a worm from a piece of good
> apple if you are not cautious enough. 
> 

Fair enough then.  Go ahead and build a CMS/Wiki from scratch that is up to 
your security standards, find a host that is up to your snuff, pay for it, 
and put up the site.  I don't have the time to continue arguing about 
imagined security holes. 

 --Jason A. Craig

On 3/29/07, jacraig@... <jacraig@...> wrote:
>
> Fair enough then.  Go ahead and build a CMS/Wiki from scratch that is up to
> your security standards, find a host that is up to your snuff, pay for it,
> and put up the site.  I don't have the time to continue arguing about
> imagined security holes.

I see you point, but give me one last favor to assure you that this
hole is not imagined - it is real and you may try it for yourself. If
it was imagined hole I would not bother myself with this discussion.

It seems like this behaviour of SF is intentional. At least the fact
that during all these years nothing changed so far allows me to think
in this way. Although everything they do for Open Source is a great
favor for OS community, sometimes community and SF need to elaborate.
There are many ways to enhance security and resources control as any
hosting does.

To conclude and make outcome of the discussion.

We do not have other choice and should stick to SF - our only way to
preserve independence and avoid dragging somebody into financial
expenses. The security problem is considered minor and is unlikely to
be exploited by members of SF. We do not have means to detect security
breach, but in case of something serious we can be notified by users.
We still do not have any backup scheme. In the end it doesn't worth to
implement any complicated backup and security detection schemes.
Everybody is aware of the problem and that is enough to act when some
obscure problems arise.

Correct me if I missed something.

-- 
--anatoly t.

Quoting techtonik <techtonik@...>:

>
> Correct me if I missed something.
>

You missed the fact that we have had enough of the banter.

Earnie -- http://for-my-kids.com

techtonik writes:
> I see you point, but give me one last favor to assure you that this
> hole is not imagined - it is real and you may try it for yourself. If
> it was imagined hole I would not bother myself with this discussion. 
> 

Sorry, I didn't mean that the SourceForge problem was imagined, I do believe 
you on that.  I meant that I don't believe Drupal has any significant XSS 
problems.  The horse has been sufficiently beaten. :) 

 --Jason A. Craig

On 3/30/07, jacraig@... <jacraig@...> wrote:
> techtonik writes:
> > I see you point, but give me one last favor to assure you that this
> > hole is not imagined - it is real and you may try it for yourself. If
> > it was imagined hole I would not bother myself with this discussion.
> >
>
> Sorry, I didn't mean that the SourceForge problem was imagined, I do believe
> you on that.  I meant that I don't believe Drupal has any significant XSS
> problems.  The horse has been sufficiently beaten. :)

It doesn't have any significant XSS problems if your database is
secured, but in this case of SQL injection vulnerability I am curious
if XSS is also possible.

-- 
--anatoly t.

On Sunday 01 April 2007 06:56, techtonik wrote:
> On 3/30/07, jacraig@... <jacraig@...> wrote:
> > techtonik writes:
> > > I see you point, but give me one last favor to assure you that
> > > this hole is not imagined - it is real and you may try it for
> > > yourself. If it was imagined hole I would not bother myself with
> > > this discussion.
> >
> > Sorry, I didn't mean that the SourceForge problem was imagined, I
> > do believe you on that.  I meant that I don't believe Drupal has
> > any significant XSS problems.  The horse has been sufficiently
> > beaten. :)
>
> It doesn't have any significant XSS problems if your database is
> secured, but in this case of SQL injection vulnerability I am curious
> if XSS is also possible.

Please, guys.  It's time to put an end to this bickering.  Anatoly, you 
have cried `Wolf!' too often.

Thanks,
Keith.