El 16/11/2016 a las 12:23, helix84 escribió:
That part is already available.
vote 1- for second part.... Not very sure about harvesting or exposing
versions and modules across system interface. Too many advantages for
networks hooligans and hackers..
Well, first, those parts are already there and publicly exposed
(xmlui, jspui, oai, rest, rdf), so the right thing to do is to make
them resilient against attacks, not to pretend they're not exposed.
Second, there must be an option for the administrator not to expose
this information (not all repositories are production and public
installations).
Well, I understood Alan´s proposal as exposing the software stack of
the Dspace installations, not only Dspace interfaces.... and telling
the world that an installation has a operating system or a database some
years old is quite sensible (IMHO), although a competent hacker could
figure out a lot of things about an installation without our help :-)
and of course our first priority has to be
make them resilient against attacks
But not every installation has the time or resources to keep its
installation updated and safe. That is the reality...
Regards
Emilio
And finally, this is supposed to actually help security. You'll be
able to register your instance (just once) along with your email
address and then get a custom-tailored notification that your
particular installation is affected by a security bug because you're
using version X.Y with module Z.
Regards,
~~helix84
Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
--
You received this message because you are subscribed to the Google Groups "DSpace
Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
