Default security or localhost
by Scott M Stark
For whatever reason our long standing use of unsecured consoles is now
being reported as a security hole. To address this, either we need to
bind to localhost by default or secure the consoles with a user that has
no access. The latter requires a post install change to add a valid role
or remove the security settings. We can't go with a default admin/admin
password.
The localhost approach would allow testsuites to continue to work as
they currently do and is probably the least intrusive change. Any other
opinions or options?
17 years, 10 months
Further jbossAS 4.2 thirdpart component updates
by Dimitris Andreadis
For practical reasons, i.e. to be able to have fully traceable thirdparty sources, that we
can always recreate/build internally, we are thinking of updating the following components:
- HSQLDB to 1.8.0.7 (from 1.8.0.2)
- JavaCC to 4.0 (from 3.2)
- qdox to 1.5, or even 1.6 (from 1.4)
- Scout to 1.0 (from 0.7 rc2)
- XDoclet to 1.2.3 (from 1.2 b3)
- Commons Discovery to 0.4 (from 0.2)
- JFreeChart to 0.9.0.21 (from 0.9.20)
this implies updating the included jcommon to 0.9.7 (from 0.6.4)
- Jaxen to 1.1 ( from 1.1 b9)
plus (for different reasons)
- JacORB to 2.3 (from 2.2.4jboss.patch1)
If you see any issues with those upgrades, speak now!
Thanks
/Dimitris
17 years, 10 months