Re: german files in SVN?
- 2007/12/9 23:18:54
- herko
SVN has a big learning curve, while editing translations (language files) doesn't require one to be a developer with SVN skills. So I'm not sure if this is a good idea.
How to deal with translations is a more general issue. I'd prefer it if the language packs are provided separately, as it decreases the upload time for the files, and normally only one language is used anyway (multilang sites excluded of course, but there isn't a rock solid solution for that yet).
Also, I would prefer if a translation is checked by at least 2 people. This to improve the quality of the translation.
What are the guidelines for translations? how formal is the language, or how technical? I would love to go through the core language files to see if we can make it more user friendly, and create some language guidelines for translators.
Herko
Re: german files in SVN?
- 2007/12/9 22:05:05
- nekro
I think that it could be posible to have all the language packs in sourceforge...
Re: Auditing Code (security wise)
- 2007/12/9 18:24:26
- davidl2
Few utilities I've found:
http://developer.spikesource.com/projects/phpsecaudit/
http://www.dragoslungu.com/2007/10/30/pixy-is-a-free-php-code-audit-tool/
http://www.php-mag.net/magphpde/magphpde_news/psecom,id,27497,nodeid,5.html
http://www.darknet.org.uk/2007/11/skavenger-source-code-auditing-tool/
Re: Auditing Code (security wise)
- 2007/12/9 15:25:11
- Dave_L
As promised. here are my notes:
Notes from SPI Dynamics workshop, Richmond, VA, 2007-04-17
This free workshop was obviously intended to encourage people to buy SPI Dynamics' web security products. But the presenter, Brett Sagenich (brett.sagenich AT spidynamics DOT com), was a security engineer, not a salesman, and he provided much information of general use. His point was that web applications present numerous potential security vulnerabilities. He demonstrated actual techniques used by attackers. The reason that he discussed these details is that while they can all be addressed by proper software design, this is very labor-intensive, while SPI Dynamics' tools perform automated detection for these vulnerabilities.
Specific vulnerabilities discussed:
1. Extraneous files such as readme's, documentation, old files
- Provides info to attackers
- Old versions of scripts may have unpatched security issues.
2. Unvalidated user input
3. Visible error messages
- May reveal information useful to attackers
- Software in use
- File system paths
- Variation in error messages in response to an attacker's input can guide him.
4. SQL injection
- iterative (trial and error)
- with error messages
- blind (based on displayed output or presence/absence of output)
5. Session hijacking
- Exploit spoofable session ID, customer ID, etc.
6. XSS (or CSS, cross-site scripting)
---
I can elaborate on some of these items, if there are questions. I know that "Unvalidated user input" is a problem often encountered with XOOPS.
---
By the way, here's a good reference I found on this topic: Open Web Application Security Project (OWASP)
german files in SVN?
- 2007/12/9 13:11:44
- sato-san
Hi all,
may I, the German language files (ISO) in SF.net?
Re: Using the trackers to document changes in the SVN
- 2007/12/9 12:26:57
- Vaughan
gets my vote.
simplicity at it's best :)
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Re: Auditing Code (security wise)
- 2007/12/9 12:20:34
- Vaughan
yes dave :) but i used telnet as just 1 example.
thanks for the offer of your notes, any information that can help improve security is a bonus.
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Re: ImpressCMS Theme
- 2007/12/9 9:34:23
- JMorris
I've got most of the logic, XHTML and CSS done. There is some work needed on fine-tuning the margins and padding, but the hardest part is done.
At this point, the images need sliced, the CSS needs color matched, and the aforementioned fine-tuning needs done.
I won't be around today and much of tomorrow. If somebody else wants to take what I've done so far and continue on it, that would be a great help!!!
Work so far attached.
Let's make this first theme a team effort!!!
ImpressCMS Professional Services: INBOX International inc.
James Morris Online | Frolicking on the playground that is the Internet...
Re: ImpressCMS - Team building
- 2007/12/9 8:02:13
- skenow
This is important to the longevity of ImpressCMS (or any project). I agree with Herko about what we need to be focusing on at this stage - a list of tasks that need to be completed and a clear overall vision, much like we did here when pulling together at Xi.
Re: GoPHP5
- 2007/12/9 7:41:21
- herko
Why not split it up?
I mean this:
the codes that build on just the current xoops 2.0.x code will have its php4 compatbility, but
the *real* impress codes (the ones that will take it away from xoops) will be php5 native.
This is what Skalpa wanted to do with XOOPS anyway: work towards a php5 native codebase. Basically, you'd have till 8.8.08 to create a superduper new php5 only system that will make the current patching xoops work obsolete.
Herko
Re: ImpressCMS - Team building
- 2007/12/9 6:07:42
- davidl2
PS: I hope no one takes offense with these ideas - they're not in concrete, but are just raised to discuss ideas.
Re: ImpressCMS - Team building
- 2007/12/9 6:04:40
- davidl2
I agree with Skenow that we should get a finalised structure - ideally based on the Draft Teams work... although I think they think on the same general lines that most people would.
We should still be able to get something arranged properly before launch date.
Until then - we've naturally organised ourselves into teams of people who can concentrate ont he different areas for now 
- rather like Herko's suggestion.
An important issue that I raised in that team many times is that we should not build walls between teams.
I feel that many people have something to contribute in other areas: an example - Skenow - who has done some great work with templates - but is thought of as a docs man...
The "Management" section of my first post is essentially ideas on how to avoid the "dog in the manger" situation. I think something like this would be an ideal situation... essentially a TEAM responsible - and not simply an individual or individuals.
Re: Auditing Code (security wise)
- 2007/12/9 4:37:30
- Dave_L
Quote:
the pages were to be viewed via say telnet
Do you mean executing the scripts from the command line, as opposed to via HTTP?
I attended a one-day seminar on web applications security last year. I'll dig out my notes and post them.
Re: Trunk no more working
- 2007/12/9 4:30:30
- Dave_L
I don't know much about TortoiseSVN. I tried using it briefly, then decided that I preferred using SVN from the command line. One advantage of the latter is that there's comprehensive documentation (the SVN book).
But TortoiseSVN is widely used, so it probably has equivalent functionality and documentation.
Re: ImpressCMS - Team building
- 2007/12/9 2:25:27
- herko
My first reaction is: don't make the same mistake I did, and the one that DJ made a thousandfold bigger: organize to get organized.
Teams are a very nice concept, but they have only temporary value. No team I have seen (and I have seen a LOT of teams!) has the stamina to keep working for more then a few months, and that is when it is working at all.
I propose to skip the roll call and name listing games and go right to the heart of the matter: projects.
In stead of creating teams who are responsible for certain sets of tasks (which implicitly means you're excusing everyone else to feel any responsibility for this work!), create projects to get a specific result in a specific way. Then, teams can be formed around these projects, but they'd be temporary and focused. Appoint one project lead who gets the task of making sure that the project is in sync with the rest, and you've got yourself a manageable structure where open collaboration is the standard.
Anyone can start a project, and ask for support from something that manages the assets.
Herko
Re: ImpressCMS - Team building
- 2007/12/8 21:19:19
- skenow
My first reaction was '3 months is too short'. The reason being it adds extra time just to reset and make transitions between the 'top man/woman'. Transitions are always unproductive.
I know the intent is to keep the potential for disaster while a particular person is in that seat, but for someone intent on doing things their way, it only takes a matter of weeks to foul things up.
My second reaction was to hold off until the draft proposal has more definition. It has some good principles and if we appear to be acting without consideration for their efforts, our credibility is at risk.
The task groups in this proposal are very close to what the proposal team is moving forward. And that is a good thing, because it deals with the actual work that needs to be done and applying the resources where needed.
A lot is happening and I feel a bit lost at times. A clear vision, as Herko was saying, is definitely higher on the list of things to be done for me.
Actual work processes (ooh, I hate that I just said that) need to be established, because they are not evident in the current XOOPS environment - security reviews and audits, code review and comment, feature/functionality/benefit analysis, testing and quality assurance, transparency and integrity are all major items.
One thing we need to keep in the front of our minds at all times - we judge ourselves by our intentions, others judge us by our actions.
ImpressCMS is a multi-language content management system for the web. It is community-built, an open source project and based on the common web technologies of PHP and MySQL.
More information
