[Geoserver-devel] Handling of GEOS-7032: Remote File Disclosure

[Johannes_Kroger]

Hi!

Earlier I posted things on Twitter and IRC that others seem to have
taken as more or less personal attacks or at least abrasive ranting. I
am sorry about that, please do not take my criticism personal. It is
easy to forget that there are people behind "words on the internet".
However I was and still am shocked at the handling of a critical
security issue in GeoServer and the neglect to protect the users. I
might be overreacting but I am reasonably sure that I am not. The
responses I got suggest that people do not realise the severity of the
issue and thus both sides get agitated. This mail might be very
"rambly", sorry.

TL;DR: GeoServer let(s) unauthenticated remote users read arbitrary
files from the servers it runs on. This was and is not properly
communicated to its users nor is the fix properly distributed.

== The issue ==

This is about https://osgeo-org.atlassian.net/browse/GEOS-7032

That is a problem with everyone's favorite XEE:
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

https://www.owasp.org/images/5/5d/XML_Exteral_Entity_Attack.pdf has
some more things one can do with this, page 28+.

This also shows directory listings.

You can gather a lot of intelligence about servers if you can read
arbitrary (as long as permissions allow) files. Being also able to see
directory listings helps a lot at discovery. Since you will access files
as the webserver (I guess?) you will also have access to things like
scripts and configurations in which you might find things like database
credentials.

As something is trying to parse the files as XML, many files result in
errors rather than their whole plain text being printed. There might be
ways around that, I am not sure.

People have suggested that it is only severe if you run GeoServer
(well, it's server) as root, but I doubt that. If this gives you full
access to any arbitrary file remotely as root, this is catastrophic. If
you can "just" read all the files you can as non-root user of the
webserver, it is more than severe enough.

While this is not a remote code execution, it has severe effects on
system security and might lead to easy discovery of a RCE. If the
severity is still not clear, please say so and I will try to research a
bit more (alternatively give me the OK to snoop around a GeoServer of
yours (production, not "empty" demo) as example). I am not a security
guy myself, just a random "hacker" in the classic sense of the word,
curious at how things work and how they break.

== The timeline so far ==

May 18th the issue was reported, including a working example exploit.
May 28th a fix was implemented in the sources.
June 18th GeoServer 2.6.4 was released

== The response ==

The reporter included a working example and some details about the
severity of the bug. While I have not tested it, the bug should also
affect Windows just the same. The severity is understated in the
comments, suggesting that it is only a major issue if GeoServer is run
as root.

Response from the GeoServer team was quick and constructive. The fix
was written and implemented in a very reasonable time frame, especially
considering it is the work of volunteers. The comment says: "Will be
part of 2.7.2 and 2.6.4, we are not cutting releases anymore from 2.5.x
nor buildling it, so a build from source will be required for those
that use 2.5.x".

Now, this was almost one month ago. The first new release that included
the fix came on June 18th for the "stable" branch of GeoServer, 2.6.4.
The issue and its fix were mentioned in the body of the announcement
with bold text.

Now if you look at http://geoserver.org/download/ , you see 2.7.1
advertised as the stable, recommended release of GeoServer. That is
2.7.1 with this issue inside, suggested for installation for new users.
And any users of the 2.7. branch are not alerted of the issue in its
code until 2.7.2 happens.

Again in other words:
You are distributing software with a known remote file disclosure issue
to any new users. You have not notified the users of the 2.7. branch in
any way about a remote file disclosure issue. You have not notified the
users of the 2.6. branch or provided a fix for 3 weeks.

The issue and its fix in 2.6. were not given any special announcement,
they were (emphasized) part of completely normal release notes. There
was no extra mail or post, no CVE. You know your users better than me
though, maybe they all always read all the release notes or maybe
GeoServer has some internal notification system (I only used it once,
years ago).

Considering how widely GeoServer is deployed, not to mention the many
government servers, this shocks me. If you look around today, you can
find more vulnerable servers than patched ones. This includes machines
at companies that I would think are being closely integrated in the
FLOSS geo community and thus should be aware of new releases (eg.
Boundless, GeoSolutions, WhereGroup).

I looked around for some common best practices or guidelines on how to
handle such severe bugs and communicating them to a community but sadly
came up empty handed.

A common procedure seems to hide the bug report from the public until
the fix iss ready and distributed to all branches. How critical issues
are then communicated differs a lot, some projects have dedicated
mailing lists for that.

Please immediately try to release an update for the 2.7. branch. Please
try to notify your users in any way about this issue that they
know it *requires* them to act to protect the security of their systems.
I would suggest a mail and blog post with a warning in its title. We all
know how easy it is to dismiss "just another release of something".

If it is possible, I would suggest requesting a CVE so that
administrators that follow those will be notified about the issue.

Thanks for reading! I hope I made it more clear why I think that this
requires a much bigger response and responsible handling.

All the best, Hannes

[jive]

Thanks for the email Hannes.

We had this discussion (on responsible disclosure) last year - and had some agreement how we would like issue of this nature to be handled.

Please take moment to review that thread so we do not cover the same ground again. As volunteers we are often passed the results of security audits in public and in private.

aside: It was not responsible to include in the issue report a demonstration of the flaw. In situations like this I would expect a user contact the project team (the steering committee as listed on our website, or Andrea who is our OSGeo project officer). The user report was understandably upset, so I did not take them to ask in this case - perhaps that was a mistake on my part.

Although the above discussion explored the issue we did not get any solid procedure change into our developers guide. Something we could put on the agenda for tomorrows Skype meeting. As a member of the community you are welcome to join that Skype meeting.

With respect to an immediate release I am not in position to volunteer my time, or any volunteer here toward that effort. What we could do is pull previous release off the website until a replacement is available next month.

Although we wish we were in position to release the software as needed in cases like this we do not have the resources as volunteers on this project. We have very carefully committed to a monthly release cycle, both to our respective employers (to keep a lid on the amount of community work that is done) and to each other (to prevent team members burning out).

What I can do is offer to help you make the release, this is just my own habit as a project lead helping new contributors take part.

···

Jody Garnett

On 22 June 2015 at 14:07, Johannes Kröger <johannes.kroeger@anonymised.com> wrote:

Hi!

Earlier I posted things on Twitter and IRC that others seem to have
taken as more or less personal attacks or at least abrasive ranting. I
am sorry about that, please do not take my criticism personal. It is
easy to forget that there are people behind “words on the internet”.
However I was and still am shocked at the handling of a critical
security issue in GeoServer and the neglect to protect the users. I
might be overreacting but I am reasonably sure that I am not. The
responses I got suggest that people do not realise the severity of the
issue and thus both sides get agitated. This mail might be very
“rambly”, sorry.

TL;DR: GeoServer let(s) unauthenticated remote users read arbitrary
files from the servers it runs on. This was and is not properly
communicated to its users nor is the fix properly distributed.

== The issue ==

This is about https://osgeo-org.atlassian.net/browse/GEOS-7032

That is a problem with everyone’s favorite XEE:
https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing

https://www.owasp.org/images/5/5d/XML_Exteral_Entity_Attack.pdf has
some more things one can do with this, page 28+.

This also shows directory listings.

You can gather a lot of intelligence about servers if you can read
arbitrary (as long as permissions allow) files. Being also able to see
directory listings helps a lot at discovery. Since you will access files
as the webserver (I guess?) you will also have access to things like
scripts and configurations in which you might find things like database
credentials.

As something is trying to parse the files as XML, many files result in
errors rather than their whole plain text being printed. There might be
ways around that, I am not sure.

People have suggested that it is only severe if you run GeoServer
(well, it’s server) as root, but I doubt that. If this gives you full
access to any arbitrary file remotely as root, this is catastrophic. If
you can “just” read all the files you can as non-root user of the
webserver, it is more than severe enough.

While this is not a remote code execution, it has severe effects on
system security and might lead to easy discovery of a RCE. If the
severity is still not clear, please say so and I will try to research a
bit more (alternatively give me the OK to snoop around a GeoServer of
yours (production, not “empty” demo) as example). I am not a security
guy myself, just a random “hacker” in the classic sense of the word,
curious at how things work and how they break.

== The timeline so far ==

May 18th the issue was reported, including a working example exploit.
May 28th a fix was implemented in the sources.
June 18th GeoServer 2.6.4 was released

== The response ==

The reporter included a working example and some details about the
severity of the bug. While I have not tested it, the bug should also
affect Windows just the same. The severity is understated in the
comments, suggesting that it is only a major issue if GeoServer is run
as root.

Response from the GeoServer team was quick and constructive. The fix
was written and implemented in a very reasonable time frame, especially
considering it is the work of volunteers. The comment says: “Will be
part of 2.7.2 and 2.6.4, we are not cutting releases anymore from 2.5.x
nor buildling it, so a build from source will be required for those
that use 2.5.x”.

Now, this was almost one month ago. The first new release that included
the fix came on June 18th for the “stable” branch of GeoServer, 2.6.4.
The issue and its fix were mentioned in the body of the announcement
with bold text.

Now if you look at http://geoserver.org/download/ , you see 2.7.1
advertised as the stable, recommended release of GeoServer. That is
2.7.1 with this issue inside, suggested for installation for new users.
And any users of the 2.7. branch are not alerted of the issue in its
code until 2.7.2 happens.

Again in other words:
You are distributing software with a known remote file disclosure issue
to any new users. You have not notified the users of the 2.7. branch in
any way about a remote file disclosure issue. You have not notified the
users of the 2.6. branch or provided a fix for 3 weeks.

The issue and its fix in 2.6. were not given any special announcement,
they were (emphasized) part of completely normal release notes. There
was no extra mail or post, no CVE. You know your users better than me
though, maybe they all always read all the release notes or maybe
GeoServer has some internal notification system (I only used it once,
years ago).

Considering how widely GeoServer is deployed, not to mention the many
government servers, this shocks me. If you look around today, you can
find more vulnerable servers than patched ones. This includes machines
at companies that I would think are being closely integrated in the
FLOSS geo community and thus should be aware of new releases (eg.
Boundless, GeoSolutions, WhereGroup).

I looked around for some common best practices or guidelines on how to
handle such severe bugs and communicating them to a community but sadly
came up empty handed.

A common procedure seems to hide the bug report from the public until
the fix iss ready and distributed to all branches. How critical issues
are then communicated differs a lot, some projects have dedicated
mailing lists for that.

Please immediately try to release an update for the 2.7. branch. Please
try to notify your users in any way about this issue that they
know it requires them to act to protect the security of their systems.
I would suggest a mail and blog post with a warning in its title. We all
know how easy it is to dismiss “just another release of something”.

If it is possible, I would suggest requesting a CVE so that
administrators that follow those will be notified about the issue.

Thanks for reading! I hope I made it more clear why I think that this
requires a much bigger response and responsible handling.

All the best, Hannes

---

Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jive]

Hannes:

Your email provides an extensive background on the risk associated with the issue.

Would you be willing to rework the content into a blog post for the website. It would help explain what is going on in the event we choose to delist the 2.7.1 release and ask users to grab a nightly build.

I do not know anything about asking for a CVE.

Jody

···

On 22 June 2015 at 14:07, Johannes Kröger <johannes.kroeger@anonymised.com> wrote:

Hi!

Earlier I posted things on Twitter and IRC that others seem to have
taken as more or less personal attacks or at least abrasive ranting. I
am sorry about that, please do not take my criticism personal. It is
easy to forget that there are people behind “words on the internet”.
However I was and still am shocked at the handling of a critical
security issue in GeoServer and the neglect to protect the users. I
might be overreacting but I am reasonably sure that I am not. The
responses I got suggest that people do not realise the severity of the
issue and thus both sides get agitated. This mail might be very
“rambly”, sorry.

TL;DR: GeoServer let(s) unauthenticated remote users read arbitrary
files from the servers it runs on. This was and is not properly
communicated to its users nor is the fix properly distributed.

== The issue ==

This is about https://osgeo-org.atlassian.net/browse/GEOS-7032

That is a problem with everyone’s favorite XEE:
https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing

https://www.owasp.org/images/5/5d/XML_Exteral_Entity_Attack.pdf has
some more things one can do with this, page 28+.

This also shows directory listings.

You can gather a lot of intelligence about servers if you can read
arbitrary (as long as permissions allow) files. Being also able to see
directory listings helps a lot at discovery. Since you will access files
as the webserver (I guess?) you will also have access to things like
scripts and configurations in which you might find things like database
credentials.

As something is trying to parse the files as XML, many files result in
errors rather than their whole plain text being printed. There might be
ways around that, I am not sure.

People have suggested that it is only severe if you run GeoServer
(well, it’s server) as root, but I doubt that. If this gives you full
access to any arbitrary file remotely as root, this is catastrophic. If
you can “just” read all the files you can as non-root user of the
webserver, it is more than severe enough.

While this is not a remote code execution, it has severe effects on
system security and might lead to easy discovery of a RCE. If the
severity is still not clear, please say so and I will try to research a
bit more (alternatively give me the OK to snoop around a GeoServer of
yours (production, not “empty” demo) as example). I am not a security
guy myself, just a random “hacker” in the classic sense of the word,
curious at how things work and how they break.

== The timeline so far ==

May 18th the issue was reported, including a working example exploit.
May 28th a fix was implemented in the sources.
June 18th GeoServer 2.6.4 was released

== The response ==

The reporter included a working example and some details about the
severity of the bug. While I have not tested it, the bug should also
affect Windows just the same. The severity is understated in the
comments, suggesting that it is only a major issue if GeoServer is run
as root.

Response from the GeoServer team was quick and constructive. The fix
was written and implemented in a very reasonable time frame, especially
considering it is the work of volunteers. The comment says: “Will be
part of 2.7.2 and 2.6.4, we are not cutting releases anymore from 2.5.x
nor buildling it, so a build from source will be required for those
that use 2.5.x”.

Now, this was almost one month ago. The first new release that included
the fix came on June 18th for the “stable” branch of GeoServer, 2.6.4.
The issue and its fix were mentioned in the body of the announcement
with bold text.

Now if you look at http://geoserver.org/download/ , you see 2.7.1
advertised as the stable, recommended release of GeoServer. That is
2.7.1 with this issue inside, suggested for installation for new users.
And any users of the 2.7. branch are not alerted of the issue in its
code until 2.7.2 happens.

Again in other words:
You are distributing software with a known remote file disclosure issue
to any new users. You have not notified the users of the 2.7. branch in
any way about a remote file disclosure issue. You have not notified the
users of the 2.6. branch or provided a fix for 3 weeks.

The issue and its fix in 2.6. were not given any special announcement,
they were (emphasized) part of completely normal release notes. There
was no extra mail or post, no CVE. You know your users better than me
though, maybe they all always read all the release notes or maybe
GeoServer has some internal notification system (I only used it once,
years ago).

Considering how widely GeoServer is deployed, not to mention the many
government servers, this shocks me. If you look around today, you can
find more vulnerable servers than patched ones. This includes machines
at companies that I would think are being closely integrated in the
FLOSS geo community and thus should be aware of new releases (eg.
Boundless, GeoSolutions, WhereGroup).

I looked around for some common best practices or guidelines on how to
handle such severe bugs and communicating them to a community but sadly
came up empty handed.

A common procedure seems to hide the bug report from the public until
the fix iss ready and distributed to all branches. How critical issues
are then communicated differs a lot, some projects have dedicated
mailing lists for that.

Please immediately try to release an update for the 2.7. branch. Please
try to notify your users in any way about this issue that they
know it requires them to act to protect the security of their systems.
I would suggest a mail and blog post with a warning in its title. We all
know how easy it is to dismiss “just another release of something”.

If it is possible, I would suggest requesting a CVE so that
administrators that follow those will be notified about the issue.

Thanks for reading! I hope I made it more clear why I think that this
requires a much bigger response and responsible handling.

All the best, Hannes

---

Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

[Bart_van_den_Eijnde1]

Thanks, Hannes, for taking the time to publicise this important issue, which will be on the agenda of Tuesday's committee meeting (in about 20 hours).

A few notes:

- Users of 2.7 releases can (and in my view should) immediately upgrade to a recent 2.7.x nightly, which will include the fix for GEOS-7032, as an interim measure; this may be preferable to your Twitter-advised action of shutting down such services

- Releases rely largely on volunteer effort; we need more volunteers on the steering committee, and there is not yet a volunteer even for the scheduled release of 2.7.2 (in over three weeks):
https://github.com/geoserver/geoserver/wiki/Release-Schedule

- My 2.6.4 release announcements included (as you note) bold all-caps warnings, which in my experience are unprecedented for this project; you are correct in pointing out that these warnings may not have drawn the attention of 2.7 users and we should do better

- I like your idea of a CVE but have no idea how to request one

Kind regards,
Ben.

On 23/06/15 09:07, Johannes Kröger wrote:

Hi!

Earlier I posted things on Twitter and IRC that others seem to have
taken as more or less personal attacks or at least abrasive ranting. I
am sorry about that, please do not take my criticism personal. It is
easy to forget that there are people behind "words on the internet".
However I was and still am shocked at the handling of a critical
security issue in GeoServer and the neglect to protect the users. I
might be overreacting but I am reasonably sure that I am not. The
responses I got suggest that people do not realise the severity of the
issue and thus both sides get agitated. This mail might be very
"rambly", sorry.

TL;DR: GeoServer let(s) unauthenticated remote users read arbitrary
files from the servers it runs on. This was and is not properly
communicated to its users nor is the fix properly distributed.

== The issue ==

This is about https://osgeo-org.atlassian.net/browse/GEOS-7032

That is a problem with everyone's favorite XEE:
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

https://www.owasp.org/images/5/5d/XML_Exteral_Entity_Attack.pdf has
some more things one can do with this, page 28+.

This also shows directory listings.

You can gather a lot of intelligence about servers if you can read
arbitrary (as long as permissions allow) files. Being also able to see
directory listings helps a lot at discovery. Since you will access files
as the webserver (I guess?) you will also have access to things like
scripts and configurations in which you might find things like database
credentials.

As something is trying to parse the files as XML, many files result in
errors rather than their whole plain text being printed. There might be
ways around that, I am not sure.

People have suggested that it is only severe if you run GeoServer
(well, it's server) as root, but I doubt that. If this gives you full
access to any arbitrary file remotely as root, this is catastrophic. If
you can "just" read all the files you can as non-root user of the
webserver, it is more than severe enough.

While this is not a remote code execution, it has severe effects on
system security and might lead to easy discovery of a RCE. If the
severity is still not clear, please say so and I will try to research a
bit more (alternatively give me the OK to snoop around a GeoServer of
yours (production, not "empty" demo) as example). I am not a security
guy myself, just a random "hacker" in the classic sense of the word,
curious at how things work and how they break.

== The timeline so far ==

May 18th the issue was reported, including a working example exploit.
May 28th a fix was implemented in the sources.
June 18th GeoServer 2.6.4 was released

== The response ==

The reporter included a working example and some details about the
severity of the bug. While I have not tested it, the bug should also
affect Windows just the same. The severity is understated in the
comments, suggesting that it is only a major issue if GeoServer is run
as root.

Response from the GeoServer team was quick and constructive. The fix
was written and implemented in a very reasonable time frame, especially
considering it is the work of volunteers. The comment says: "Will be
part of 2.7.2 and 2.6.4, we are not cutting releases anymore from 2.5.x
nor buildling it, so a build from source will be required for those
that use 2.5.x".

Now, this was almost one month ago. The first new release that included
the fix came on June 18th for the "stable" branch of GeoServer, 2.6.4.
The issue and its fix were mentioned in the body of the announcement
with bold text.

Now if you look at http://geoserver.org/download/ , you see 2.7.1
advertised as the stable, recommended release of GeoServer. That is
2.7.1 with this issue inside, suggested for installation for new users.
And any users of the 2.7. branch are not alerted of the issue in its
code until 2.7.2 happens.

Again in other words:
You are distributing software with a known remote file disclosure issue
to any new users. You have not notified the users of the 2.7. branch in
any way about a remote file disclosure issue. You have not notified the
users of the 2.6. branch or provided a fix for 3 weeks.

The issue and its fix in 2.6. were not given any special announcement,
they were (emphasized) part of completely normal release notes. There
was no extra mail or post, no CVE. You know your users better than me
though, maybe they all always read all the release notes or maybe
GeoServer has some internal notification system (I only used it once,
years ago).

Considering how widely GeoServer is deployed, not to mention the many
government servers, this shocks me. If you look around today, you can
find more vulnerable servers than patched ones. This includes machines
at companies that I would think are being closely integrated in the
FLOSS geo community and thus should be aware of new releases (eg.
Boundless, GeoSolutions, WhereGroup).

I looked around for some common best practices or guidelines on how to
handle such severe bugs and communicating them to a community but sadly
came up empty handed.

A common procedure seems to hide the bug report from the public until
the fix iss ready and distributed to all branches. How critical issues
are then communicated differs a lot, some projects have dedicated
mailing lists for that.

Please immediately try to release an update for the 2.7. branch. Please
try to notify your users in any way about this issue that they
know it *requires* them to act to protect the security of their systems.
I would suggest a mail and blog post with a warning in its title. We all
know how easy it is to dismiss "just another release of something".

If it is possible, I would suggest requesting a CVE so that
administrators that follow those will be notified about the issue.

Thanks for reading! I hope I made it more clear why I think that this
requires a much bigger response and responsible handling.

All the best, Hannes

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

[Andrea_Aime4]

On Mon, Jun 22, 2015 at 11:07 PM, Johannes Kröger <
johannes.kroeger@anonymised.com> wrote:

Hi!

Earlier I posted things on Twitter and IRC that others seem to have
taken as more or less personal attacks or at least abrasive ranting.

The amount of noise you've been making for this one on twitter, even after
the OSGeo president (no less) asked you to use a more constructive
attitude would make many think you've simply trying to discredit the
project.
We haven't seen that kind of attitude in years.

Mind, I'm not saying we haven't made mistakes, but ask yourself, with
thousands of users
subscribed to the users mailing list, hundreds subscribed to the devel
list, and with so many with a twitter account, how
comes we don't have tens of people raising hell?
Many may not have noticed, but I guess those that did, do understand
the volunteer nature of the project.

I am sorry about that, please do not take my criticism personal.

Nobody took it as personal criticism, people are just defending the project
and the community.

It is
easy to forget that there are people behind "words on the internet".
However I was and still am shocked at the handling of a critical
security issue in GeoServer and the neglect to protect the users.

I guess you have the wrong impression about the community around here.
We are not Linux, nor Apache, we don't have a large and well funded
organization
that would allow to get people dedicated to these issues, we simply
tried to manage it the best we can with the limited resources at hand.
I put time to fix the issue, my company sponsored the time to do the
backports
from dev to stable and maintenance, Boundless people reviewed promptly,
Ben did the 2.6.4 release, someone else will put the time to do the 2.7.2
release

Not saying the above cannot be improved btw, we can certainly use some help
there.

Any attempt at improving the current situation in a more
predictable, better managed, with faster response times (which I agree
would be desirable)
will have to answer one simple question: "with what resources?".

As Jody said, people have the option of downloading a nightly build,
especially on the
stable series, the releases are really nothing more than a procedure to
tag the nightly of the right day in the month (the 18th), unless of course
the tests in the build or the nightly OGC conformance tests failed
(which is a rare occurrence).
Yet, the release procedure still eat around 4 hours of someone's time
(someone
with admin rights in all the key areas), and the people routinely doing
releases are
a handful, all busy up to their eyeballs with their daily work already.
(check the release schedule, it has the release managers for each release:
https://github.com/geoserver/geoserver/wiki/Release-Schedule)

Next time you see something wrong in the project we'll be happy to hear
about it, and if you actually understood what Jeff McKenna tried to explain
you,
you'll hopefully start your sentences with "I'm concerned with XYZ, how can
I help?".

If instead you're starting writing something like "I'm shocked" take a deep
breath,
think about it, and reword.... incidentally, that's what I usually do when
I'm writing about something that
bothers me: the mail gets often rewritten 2-3 times, progressively toning
it down (
and people still do complain I'm too direct after all that work :-p)

You're also welcomed to join tonight's Skype meeting, where the issue will
be discussed
and people will bring to the table whatever their can offer to improve the
management of
this kind of issues, now and in the future.
The meeting will be 9.30pm CET, send me, Jody or Ben your skype id in case
you
want to join.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[Robert_Coup]

Hi Ben/Jody,

On 23 June 2015 at 00:23, Ben Caradoc-Davies <ben@anonymised.com> wrote:

- I like your idea of a CVE but have no idea how to request one

The best guide I've come across is this:
https://github.com/RedHatProductSecurity/CVE-HOWTO

This issue has been public (on the bug tracker & mailing list, even before
today's visibility), so the oss-security approach is best. More details on
that are here: http://oss-security.openwall.org/wiki/disclosure/cve

Essentially, send an email to the list with some very broad-strokes
details, and you get a CVE number allocated.

HTH,

Rob