31
Herko
Re: has this security been resolved?
  • 2007/5/4 9:24

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


and the group.php sql injection bug isn't serious because the system is only vulnerable when logged in as administrator of a website. And administrators already have the rights to change everything anyway. You can't secure against misuse of properly given access and administration rights. ANyway, with access to the groups administration section, you can give anyone any rights anyway. The hole is there, but it doesn't leak unless leaking is part of the goal.

Herko



32
Herko
Re: Why XOOPS behave abnormal when include in a frame ?
  • 2007/5/3 19:56

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


BEcause XOOPS needs the URL used to be the real location of the website in order to check if the requests made to the scripts come from the correct site and logged in user.

If a redirect URL is used, this isn't the case, and the checks fail. This isn't a bug, it's actually a feature. Some hosting environments are just not fit for XOOPS hosting. Microsft .ASP hosting is one of them, and redirect hosting is another

Herko



33
Herko
Re: SmartMail
  • 2007/5/1 11:43

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


All posts in this forum are about gathering description texts for the new repository

Herko



34
Herko
Re: SmartMail
  • 2007/5/1 7:13

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


Since this is labelled Alpha, it should be unavoidably clear that this module is released for testing and development purposes only, and not to be used in any kind of production environment.

For beta's it should be noted that it is a testing release and is not recommended for production websites, and RC's should be noted that it is not yet labelled as stable, and that bugs should be reported to the developer.

Herko



35
Herko
Re: This PAge cannot be displayed due to an internal error
  • 2007/4/29 14:53

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


Quote:
Error: Unable to connect to database

Obviously, the XOOPS system is unable to connect to the database at that time. Does this show with all pages, or just one? Do you get somep ages that load properly? Are you sure your database info in mainfile.php is correct?

Herko



36
Herko
Re: Module: Protector description
  • 2007/4/22 8:42

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


skenow wrote, and I cleaned it up just a bit (less technical talk, XOOPS all caps, some minor language corrections).

Modulename and version
Quote:
Protector 3.02


Short description
Quote:
XOOPS Protector is a module to defend your XOOPS2 powered website from various malicious attacks. In the event of an attempt to attack your website, Protector blocks the attack and the attacker.

PLEASE NOTE: The level of security of your website depends on the quality of the scripts used as much as the configuration of the webserver the website is hosted on. Protector adds an extra security layer to the XOOPS scripts.


Detailed description
Quote:
This module can protect a various kind of attacks like:

- DoS (Denial of Service)
- Bad Crawlers (like bots collecting e-mails...)
- SQL Injection
- XSS (Cross Site Scripting -not all though)
- System globals pollution
- Session hi-jacking
- Null-bytes
- Directory Traversal
- Various methods of CSRF (Cross SIte Request Forgery -fatal in XOOPS <= 2.0.9.2)
- Brute Force multiple login attacks
- Camouflaged Image File Uploading (== IE Content-Type XSS)
- Executable File Uploading Attack
- XML-RPC's eval() and SQL Injection Attacks
- SPAMs for comment, trackback etc.

XOOPS Protector defends your XOOPS 2.x poewered website from these attacks, and records them in its log.


Version
Quote:
3.02


Publisher
Quote:
GIJOE


Home Page
Quote:

System Requirements
Quote:
XOOPS 2.x, PHP 4.x+, MySQL 3.23+


Screenshot links
Quote:



37
Herko
Re: Repository: Rules discussion
  • 2007/4/21 19:29

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


What about these:

- naming convention: rules for naming a XOOPS module mod_x2.0/2/3/all_name_version.ext
- module structure: the downloaded archive extracts to htdocs/modules/modulename folder (similar to the XOOPS core distro), including a docs/ folder and the full paths to the module folder
- versioning: in the repository, please use one entry per module, not per module version. This means updating a module entry when a newer version is released.
- language files: added to the module package (high maintenance) or as separate downloads (where?)

And these:
- reviews of modules (each month a new module review?)
- tested or not
- central download location or decentralised
- module packs

Herko



38
Herko
Re: is it time for a lead project manager?
  • 2007/4/21 8:33

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


Quote:

MadFish wrote:
Quote:
If a select few are responsible, things are going to be done their way, so they can control the risks of being held accountable. This is truly unavoidable.


No, this is the closed team model. It is exactly the opposite of what I mean by open teams.

The leader of an open team would be responsible for coordinating the effort of the wider community for some aspect of xoops. That might mean:

* Maintaining a list of tasks that need doing
* Trying to encourage people to take on particular jobs
* Encouraging people to work together
* Encouraging debate on a common direction
* Encourage community comment and review on technical contributions and suggestions from community members
* Delegating any or all of the above to others!

Anyone interested community member could:
* Take on tasks that need doing
* Propose new tasks or improvements
* Provide input on direction of that aspect of xoops
* Help review technical contributions and suggestions from community members.

This is an open way of working.

This is the way the Core and Management Teams have worked in the past. Exactly like that. I am serious, ALL the above is what you will find, in various degrees of openness and closedness.

This isn't truly open, because there is a scarcity of resources, and these need to be allocated by the coordinator.
This means: deciding 'what needs to be done' based on concepts and ideas that are not the result of a public consent mechanism (as getting this public consent at this strategic level is impossible, ask any organization). This will be based on what the selct few feel 'is best for everyone and the project'. This can be monitored and judged by an accountablility system, but that's only *after* the fact, and therefore counterproductive.
Since there aren't enough resources to do 'all the work' (everything that 'needs to be done'), judgement calls need to be made. This by default means negotiations, because people will have to free their personal resources to make it happen.
Encouraging people definately isn't enough. Especially if that coordinator is to be held accountable for the resource allocation choices made. Then this coordinator will need to be given the resources to hold people to their promises, to make them to something slightly different then they would themselves in the interest of the common goal and plan. And this can never be the case, because this would be in direct conflict with the openness.

There hasn't been clear community census on anything, ever. There have been many many looong wishlists, but only very few people willing to add their resources to the common pool to make them happen. Most of the time permission is asked to actually do something. Why? Isn't true openness about being able to add value? Then do so. There doesn't need to be a leader that will allow you to do anything. If theres a need for coordination, this can be done by the people actually doing it. And then they can be held accountable by their peers for failing to do so. Why make someone else responsible for that, when it *should* be placed at the source?

Like I siad before, if this is about leadership, it should be about everyone becoming a leader and taking responsibility. Not delegating the responsibility to someone else, without giving them the tools to actually do the work. Why make someone responsible for everyone else's failure to think about the consequences and coordinate their efforts?

True openness means everone is a leader and responsible, and accountable by his or her peers. Isn't that what open source is all about? Freedom to express yourself?

Herko



39
Herko
Re: calling phppp & skalpa, please comment on this thread!
  • 2007/4/21 6:40

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


Quote:

MadFish wrote:
An *open team structure* will make it a success. Past attempts were all closed teams, with fixed membership, that prevented others from contributing, that ran into labour shortages, and THAT is why they failed.

We can't have no leadership at all, someone has to be responsible. But let the teams be a mechanism for coordinating and reviewing the wider community effort, not closed shops*.


You're right, and you're wrong. Let me explain
You're right the previous teams were too closed by design. This could be part of the reason why they failed.

Whether an open team structure will be more successful I doubt. And you provide the argument for that yourself (so this is where you are incorrect IMHO).
Transparency and an open structure are means to an end. And the end here is to provide the means to make everyone take responsibility. Is isn't a no-strings-attached situation, true openness. It means that everyone is responsible, and accountable too. Openness is a means for everyone to take action, not just hold those who *do* take action accountable at all times.
And this is where it conflicts with leadership. Having someone responsible by default means that there isn't true openess and transparency. If a select few are responsible, things are going to be done their way, so they can control the risks of being held accountable. This is truly unavoidable.
And this is why a truly open team structure is bound to fail by design as well. You can't have some people responsible with an open membership structure where anyone can get in and out anytime they like. There's no way to make someone accountable for their choices, and thus responsible and open. And transparency doesn't solve that particular problem.

So, the truth is probably in finding a working balance between leadership and full transparency.

That is why I propose a self-organising community. Let the core devs deal with code development and decision making methods common in open source development. Let the Foundation take care of corporate communications and product promotion, which ever way the project evolves. And let the support community organise itself, without an all-overseeing body of people responsible.

Herko



40
Herko
Re: calling phppp & skalpa, please comment on this thread!
  • 2007/4/20 21:09

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


Quote:

eric235u wrote:
i have just clearly shown that the common developement tools are NOT being used. that is fact.

And we've disputed this several times. Progress is slow, but measurable on sf.net. Your point was that sf.net should be used for all core development activity and that this isn't the case. That point has been refuted. ALL development that takes place, is done publicly on sf.net. If that means that there hasn't been a lot of development, then you're right. But these last few days Rowd has started accepting bug reports and submitted fixes. She is part of the core development team, and thus the development of XOOPS continues.

Ignoring arguments is what causes air to heat up

@JCDunnart: lol! And you're right. We should get back on topic: how things can be *done*.

Herko




TopTop
« 1 2 3 (4) 5 6 7 ... 309 »



Login

Who's Online

175 user(s) are online (73 user(s) are browsing Support Forums)


Members: 0


Guests: 175


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Oct 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits