So it turns out that suppressing the version string itself is trivial - a one-liner. However, that string is almost always enclosed in a construct of some sort - like an XML or HTML comment. I think those would need to be suppressed too by just checking to see if the version string is empty. Would folks agree? There aren't that many occurrences impacted, I count eight of them. --Steve
On Wed, Feb 16, 2022 at 9:21 AM Steve Lime <[email protected]> wrote: > I should never send an email and then go to bed... great discussion! > Anyway, I was thinking about this in terms of version obfuscation for > security purposes. I mean why advertise that specific information if you > don't have to - at least make it a little challenging (and check a box). > Obfuscating you're using mapserver altogether would be much more difficult, > if not impossible. I could see doing things like supporting customizable > error templates, suppressing function names in error messages, etc... > Certainly not fool proof of course. > > I think the configuration file can really provide value here... > > --Steve > > On Wed, Feb 16, 2022 at 7:18 AM Michael Smith < > [email protected]> wrote: > >> Agree with you that’s it’s a standard checklist item (in DoD for STIGs). >> But fundamentally useless. The security auditors agree but yeah, checklist >> folks are generally not persuadable. I can see a config option. >> >> >> >> Mike >> >> >> >> >> >> -- >> >> Michael Smith >> >> US Army Corps of Engineers >> >> Remote Sensing/GIS Center >> >> >> >> >> >> *From: *MapServer-dev <[email protected]> on behalf >> of "Nash, Edward" <[email protected]> >> *Date: *Wednesday, February 16, 2022 at 7:15 AM >> *To: *MapServer Dev Mailing List <[email protected]> >> *Subject: *Re: [mapserver-dev] Dropping Version Output? >> >> >> >> It may or may not be pure security theatre (personally, I’d tend to agree >> with you on that), but ‘round these parts then not publishing the versions >> of external software components used is pretty high up on standard >> checklists for securing systems (and is low-hanging fruit for anyone to >> check, so shows up pretty quickly), so being able to configure it out would >> save plenty of hassle. >> >> >> >> Ed >> >> >> >> *Von:* MapServer-dev [mailto:[email protected]] *Im >> Auftrag von *[email protected] >> *Gesendet:* Mittwoch, 16. Februar 2022 12:37 >> *An:* Tom Kralidis <[email protected]> >> *Cc:* MapServer Dev Mailing List <[email protected]> >> *Betreff:* Re: [mapserver-dev] Dropping Version Output? >> >> >> >> Also, I’d say that any perceived extra security by not having this info >> in the response is not really security, just security theatre. >> >> >> >> Keep it in. >> >> Michael Smith >> >> US Army Corps >> >> >> >> On Feb 16, 2022, at 6:34 AM, Tom Kralidis <[email protected]> wrote: >> >> >> >> I would suggest keeping at least the version somewhere in the responses >> (i.e. current behaviour, or >> >> move to an HTTP header). For scenarios where users do not have access to >> the deployment environment, >> >> this information is critical. >> >> >> >> ..Tom >> >> >> >> On Tue, Feb 15, 2022 at 8:49 PM Steve Lime <[email protected]> wrote: >> >> What do folks think about dropping the version output from MapServer? That >> is, output like: >> >> >> >> <!-- MapServer version 7.6.4 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ >> SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV >> SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER >> SUPPORTS=WCS_SERVER SUPPORTS=GEOS SUPPORTS=POINT_Z_M SUPPORTS=PBF >> INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE --> >> >> I'm not sure that advertising version and supported components makes >> sense anymore. Might be able to make it tunable via the config file but I'm >> not sure that's even necessary. >> >> >> >> --Steve >> >> _______________________________________________ >> MapServer-dev mailing list >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> >> _______________________________________________ >> MapServer-dev mailing list >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> >> _______________________________________________ MapServer-dev mailing >> list [email protected] >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> _______________________________________________ >> MapServer-dev mailing list >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> >
_______________________________________________ MapServer-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-dev
