Is the source for the actual scanning available?

[carehart]

I see that the source is available here for the file find feature and some other aspects, but when I search the codebase (here in github) for a string like "mysql_have_ssl" (shown in the screenshot of the tool's output on the readme here and the vendor's front page), no results are returned.

Is it perhaps that the code doing the actual analysis is not available as open source? I could understand that, if it's regarded as the "secret sauce", and this cli is just a way to use that proprietary analysis engine via the CLI against images only. I just wanted to confirm.

And if that's so, is it also that any extension of the tool to support a new config file would have to be built only by the vendor? Thanks.

[ioah86]

Hello @carehart . Thank you for your inquiry.

You are correct, the checks are part of secret sauce. We include all kinds of modern security benchmarks, but also have some which are extracted from the manuals directly and/or from best practice observed in the field.

The extraction of the configuration files is open source and part of this project. We found that very often, users are not aware of their configuration files and where to find them. This is why we created this open source project. It will raise awareness and ensure that future Docker images are as secure as possible.

To your second question: To include the checks into the analysis would be something that the CoGuard Team will do. If you wish for some service and its configurations to be included, please create an issue ticket here, and we will include it as quickly as possible. Right now, our supported list of services for which we find configuration files is in this folder : https://github.com/coguardio/coguard-cli/tree/master/src/coguard_cli/image_check/config_file_finders

It covers a baseline, and we are happy to expand upon request and take input for the community. Feel free to add something you would love to see there.

I hope that answers your question and I am looking forward to your further feedback.

[carehart]

Thanks for all that. I was indeed aware of the supported finders. As for your willingness to consider adding more, that's great. Since it requires your effort and is not something we can contribute to, I realize you will have to weigh efforts against the likelihood of people using the tool with that new service config analysis.

I'll say first that one I'd work with that many others may is Apache Tomcat. Another (which may seem too niche, but still has tens of thousands of folks using it) is Adobe ColdFusion (which is in fact deployed by default atop Tomcat, so getting Tomcat config analysis would be at least a step in the right direction.)

If you may lean on individuals as subject matter experts to assist in finding those resources, best practices, and security recommendations, I can help with CF for sure. You may have little problem finding such resources for Tomcat. But again I'll understand if you may deem either to be still too niche for the effort.

[ioah86]

Hello @carehart . Indeed, Tomcat is high up on our backlog, although we love Tomcat for having mostly great default configurations. They need to be checked though for the case where they have been overwritten.

As per CF: You are the first one mentioning it. Looking into it, this may be a wonderful idea. We put it into the backlog and will connect with you offline when we get to it. Sometimes the niches are the ones with the greatest need.

Does that sound good?

[carehart]

Sure, thx.

[ioah86]

@carehart coguard-cli in version 0.1.15 is now supporting tomcat.

[carehart]

Thanks for that news. I downloaded and installed the tool today, per the readme.md here. But when I ran it against the Tomcat image (also downloaded just tonight), I got this error: Docker version 20.10.14, build a224086 detected. ←[36mSCANNING IMAGE ←[0mtomcat 2022-08-04 00:07:58,113 [ERROR] Failed to extract the image filesystem: maximum recursion depth exceeded while calling a Python object We were unable to extract any known configuration files from the given image name. If you believe that this is due to a bug, please report it to info@coguard.io

Could it be perhaps that the coguard version I got via this download tonight is not the 0.0.15 version that you say now supports Tomcat? To be clear, the readme.md makes no mention of how to even check the version (via the cli), let alone how to obtain any specific version.

I realize this is getting off the original topic. If you may prefer to split this into another topic I'd understand. Thanks.

[ioah86]

That is interesting, sine I ran it through the original tomcat image and get this:

coguard docker-image tomcat

          XXXXXXXXXXXK
      xXXXXXXXXXXXXXXXXXXl
    XXXXX.            ;XXXXO       .XXXXXXXXXX     oXXXX        XXXXc       xXXXX'       'XXXXXXXXXXXXO     XXXXXXXXXXX;
  lXXXx    lXXXXXXXX,    0XXX;   cXXXXXXXXXXXXXX.  oXXXX        XXXXc      :XXXXXX       'XXXXXXXXXXXXXXX.  XXXXXXXXXXXXXX'
 dXXX.  .XXXXXx  0XXXXX    ...  dXXXX'      cXXXX. oXXXX        XXXXc     .XXXXXXX0      'XXXX'      OXXXX  XXXXo     .XXXXk
;XXX   xXXX    do   .XXXc      'XXXX,              oXXXX        XXXXc     XXXX.oXXXd     'XXXX'      ,XXXX. XXXXd       XXXXd
0XXl  ;XXk     ,,     KXX.     lXXXX               oXXXX        XXXXc    OXXXl  0XXX:    'XXXX'     .XXXXk  XXXXd       lXXXX
XXX:  oXX: cll.  ,ll: oXX;     oXXXX    .XXXXXXXXo oXXXX        XXXXc   oXXXO   .XXXX.   'XXXXXXXXXXXXXX;   XXXXd       lXXXX
OXXo  ;XXO     do     KXX.     cXXXX.   .XXXXXXXXo oXXXX        XXXXc  ;XXXX     :XXXX   'XXXXXXXXXXXXl     XXXXd       xXXX0
;XXX.  oXXX    ,,   .XXX:      .XXXXo        XXXXo lXXXX       .XXXX: .XXXXXXXXXXXXXXXO  'XXXX'   .XXXXd    XXXXd      ,XXXX;
 oXXX.   XXXXXX:lXXXXXK   ;XXX: .XXXXX.      XXXXo  XXXXX     .XXXX0  XXXXx        XXXXo 'XXXX'    .XXXX0   XXXXd    .XXXXX,
  cXXXO    ;XXXXXXXX.    XXXX'    xXXXXXXXXXXXXXX.   kXXXXXXXXXXXXd  kXXXX         ,XXXX:'XXXX'      XXXXK  XXXXXXXXXXXXXl
    KXXXX;            lXXXXx         'XXXXXXX           cXXXXXX;    lXXXX,          dXXXXlXXXX'       KXXXX XXXXXXXXK
      oXXXXXXXXXXXXXXXXXX:
          OXXXXXXXXXXd

Docker version 20.10.17, build 100c70180f detected.
SCANNING IMAGE tomcat
 Found configuration file /usr/local/tomcat/conf/server.xml
 Found configuration file /usr/local/tomcat/conf/web.xml
 Found configuration file /usr/local/tomcat/conf/context.xml
SCANNING OF tomcat COMPLETED
Scan result_jsons: 22 checks failed, 12 High/3 Medium/7 Low
 X Severity 5: tomcat_disable_shutdown_port
Documentation: Tomcat, by default, listens on port 8005 for messages with a shutdown request. The message by default is
               `SHUTDOWN`, which of course could be probed. One should change this value to a random one not known to
               attackers, if one is not disabling the shutdown port explicitly.  Remediation: Ensure that in the `server.xml`
               file, inside the `Server` tag, the attribute `shutdown` attribute is set to anything but `SHUTDOWN`.  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/config/server.html
 X Severity 5: tomcat_shutdown_different_value
Documentation: Tomcat, by default, listens on port 8005 for messages with a shutdown request. The message by default is
               `SHUTDOWN`, which of course could be probed. One should change this value to a random one not known to
               attackers, if one is not disabling the shutdown port explicitly.  Remediation: Ensure that in the `server.xml`
               file, inside the `Server` tag, the attribute `shutdown` attribute is set to anything but `SHUTDOWN`.  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#server.xml
 X Severity 5: tomcat_ensure_autodeploy_false
Documentation: Tomcat allows deployment of applications on runtime. This can be used by malicious actors to deploy their own
               applications, and hence should not be allowed.  Remediation: For every `Host` tag in the `server.xml` file,
               ensure that the attribute `autoDeploy` is set to `false` (default is `true`).  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/config/host.html
 X Severity 5: tomcat_deploy_on_startup_false
Documentation: Tomcat allows deployment of applications upon startup. This can be used by malicious actors to deploy their own
               applications, and hence should not be allowed.  Remediation: For every `Host` tag in the `server.xml` file,
               ensure that the attribute `deployOnStartup` is set to `false` (default is `true`).  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/config/host.html
 X Severity 5: tomcat_do_not_let_root_start_tomcat
Documentation: There is a way to ensure that Tomcat is not started by the root user, which would give it root-privileges.
               Remediation: In the `server.xml`, ensure that a `Listener` tag is present, with  the attribute `className` being
               `org.apache.catalina.security.SecurityListener` and `root` not being part of the comma separated list in the
               attribute `checkedOsUsers` (default is root).  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#Security_Lifecycle_Listener_-
               _org.apache.catalina.security.SecurityListener
 X Severity 4: dockerfile_last_user_should_be_non_root
Documentation: When creating a docker container, it is possible to set the user who is actually running the application and any
               command on the container. It is important to specifically use the `USER` directive in any Dockerfile to ensure
               that the user is not root and has unnecessary privileges.  Remediation: Have at least one `USER` directive in
               your Dockerfile, and the last user directive should not reference the root user or root group.  Source:
               https://docs.docker.com/engine/reference/builder/#user
 X Severity 4: tomcat_error_page_not_debug
Documentation: The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page
               is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential
               attacker. This should be avoided.  Remediation: Ensure that in any `web.xml` file that there is a `<error-page>`
               tag right below the `<web-app>` tag. Inside the `<error-page>` tag, there should be a tag of the kind
               <exception-type>java.lang.Throwable</exception-type>, and a <location> tag with a custom error-page.  Source:
               https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502
 X Severity 4: tomcat_require_certificate_authentication
Documentation: The best way to authenticate clients to Connectors is via certificate authentication. That should be enforced
               for every connector.  Remediation: For every `Connector` tag in the `server.xml` file, ensure that the attribute
               `clientAuth` is set to `true`, and for every `SSLHostConfig` tag, ensure that the `certificateVerification`
               attribute is set to `required`.  Source: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-
               _SSLHostConfig
 X Severity 4: tomcat_ssl_enabled_for_all_connectors
Documentation: No communication should be done without encryption. Hence, all Connectors should have SSL enabled.  Remediation:
               For every `Connector` tag in the `server.xml` file, ensure that both the attributes `SSLEnabled` and `secure`
               are set to `true` (defaults are `false`).  Source: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
 X Severity 4: tomcat_do_not_use_http_scheme
Documentation: No communication should be done without encryption. Hence, all Connectors should not have HTTP as a scheme
               enabled.  Remediation: For every `Connector` tag in the `server.xml` file, ensure that the attribute `scheme` is
               not set to `http` (default is `http`).  Source: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
 X Severity 4: tomcat_ensure_deploy_xml_is_false
Documentation: Developers may assign increased privileges to their applications, which they should not do. The way to prevent
               it is to forbid the deployment of custom `context.xml` files for deployments.  Remediation: For every `Host` tag
               in the `server.xml` file, ensure that the attribute `deployXML` is set to `false` (ambiguous default).  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/config/host.html
 X Severity 4: tomcat_do_not_allow_cross_context
Documentation: There is a setting to allow an application to call a request dispatcher for other applications on the same host.
               This sort of privilege can be potentially exploited to gain access to restricted resources.  Remediation: Ensure
               in the `context.xml` file that any `Context` tag does have the attribute `crossContext` set to `false` (no clear
               default in the documentation).  Source: https://tomcat.apache.org/tomcat-9.0-doc/config/context.html
 X Severity 3: tomcat_hide_server
Documentation: The lesser anyone connecting to the server knows about the underlying architecture, the better. Any Connector
               instance returns a well-known server string by default, revealing that Tomcat is being used. This should be
               remediated.  Remediation: Ensure that in any `server.xml` file that every `Connector` instance does have a
               random string in the attribute `server`.  Source: https://tomcat.apache.org/tomcat-9.0-doc/security-
               howto.html#Connectors
 X Severity 3: tomcat_do_not_use_certain_realms
Documentation: Tomcat can use different implementations to handle user authentication and authorization. Certain
               implementations are not recommended for production use, and this check fails if one of them is encountered.
               Remediation: Ensure that for any `Realm` tag in the `server.xml` file, the `className` attribute is not one of
               the following:   - MemoryRealm,   - JDBCRealm,   - UserDatabaseRealm .  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
 X Severity 3: dockerfile_create_volume_for_var_log
Documentation: In linux systems, important operating system logs are stored in the `/var/log` subfolder. This folder should
               always be made available to the host through a volume, so that log tracking and log analysis systems can capture
               them.   Remediation: In every Dockerfile, there should be a VOLUME directive which has `/var/log` as an
               argument.  Source: https://docs.docker.com/engine/reference/builder/
 X Severity 2: dockerfile_only_one_cmd_instruction
Documentation: The `CMD` directive specifies the final command that is executed when running the container. This should be
               unique.   Remediation: Ensure that there is at most one `CMD` directive in the Dockerfile.
 X Severity 2: tomcat_remove_default_connectors
Documentation: By Default, Apache Tomcat's configuration defines two Connectors, one listening on port 8080 and the other on
               8009. These default connectors, unless altered and used for a purpose, should be removed, as they otherwise are
               potential doors for probingthe server.  Remediation: Ensure in the `server.xml` file that any Connector instance
               does not use the ports 8009 or 8080.  Source: https://tomcat.apache.org/tomcat-9.0-doc/security-
               howto.html#Connectors
 X Severity 2: dockerfile_container_healthcheck_parameter
Documentation: Dockerfiles have an instruction called `HEALTHCHECK`. It enables a user to define a command to figure out if the
               program(s) running inside the container are working properly. It is generally advisable to have healthchecks in
               place to assist monitoring of running containers.  Remediation: Have at least one `HEALTHCHECK` instruction in
               your Dockerfile.  Source: https://docs.docker.com/engine/reference/builder/#healthcheck
 X Severity 1: dockerfile_env_and_arg_defined_and_right_away_used
Documentation: When creating Docker images that use environment variables or build arguments, it is advisable to position the
               `ARG` or `ENV` directives close to their actual uses, since otherwise the caching for building the images is not
               greatly used.  Remediation: Every variable defined by an `ENV` or `ARG` directive should be used within the next
               five commands inside the Dockerfile.
 X Severity 1: dockerfile_only_one_definition_per_env_statement
Documentation: The `ENV` statement allows multiple definitions. This should be avoided for readability reasons, as well as
               pitfalls like variables not being evaluated if defined within the same `ENV` directive.   Remediation: Ensure
               that every `ENV` directive has only one assignment.
 X Severity 1: tomcat_log_effective_web_xml
Documentation: To avoid long debugging if a web application is not deployed as intended, it is useful to see which web
               applications exactly have been deployed. Tomcat allows extended logs to be shown at startup to see which
               `web.xml` files have been loaded or not.  Remediation: Ensure in the `context.xml` file that any `Context` tag
               does have the attribute `logEffectiveWebXml` set to `true` (default is `false`).  Source:
               https://tomcat.apache.org/tomcat-9.0-doc/config/context.html
 X Severity 1: dockerfile_do_not_use_add
Documentation: Dockerfiles have two directives that allow you to add files from the machine where you build the image into the
               image, namely `COPY` and `ADD`. Both are technically similar, but `ADD` also has side-effects like automated
               decompression of archives. It is generally recommended to only use `COPY`  Remediation: Remove any `ADD`
               directive in your dockerfile and replace it with `COPY`.  Source:
               https://docs.docker.com/engine/reference/builder/#copy
➜  ~ 

Can you specify which OS and version of python you are using?

Plus, if you can run it with --logging-level DEBUG, there might be some good output that may be useful to debug.

[carehart]

Thanks so much for helping out, Albert.

So yep, I'm on Windows, and I found a workaround/requirement: I had to run the command prompt "as admin" when running goguard. That worked and scanned the Tomcat image...at least on one machine.

And I share below more info, including the results of that debug option (which did not help) and some other observations to help you or others who may trip over this problem.

1) So again I'm indeed running coguard (and Docker) on Windows (don't hold that against me, please, folks. People have their reasons, that are legit.) And to be clear, I am running Docker Desktop for Windows (which as you may know implements a Linux VM via WSL, transparently to us, such that we run our Docker commands at the Windows command prompt or powershell. I'm doing the former.)

2) As for the need to run the cmdline as admin to run coguard against that Tomcat image, I will note FWIW that this was NOT needed to run it against the Docker hello-world image. I had tried that first, even last night. So there seems to be something different about the Tomcat image that requires that, which may be worth your understanding.

3) Back to trying coguard against the Tomcat image when NOT running as admin, I had tried adding the --logging-level DEBUG, and it added just the one line about the call out to your service, but still failed: Docker version 20.10.14, build a224086 detected. 2022-08-04 11:43:49,677 [DEBUG] Starting new HTTPS connection (1): portal.coguard.io:443 2022-08-04 11:43:50,031 [DEBUG] https://portal.coguard.io:443 "POST /auth/realms/coguard/protocol/openid-connect/token HTTP/1.1" 200 2389 ←[36mSCANNING IMAGE ←[0mtomcat 2022-08-04 11:44:24,107 [ERROR] Failed to extract the image filesystem: maximum recursion depth exceeded while calling a Python object We were unable to extract any known configuration files from the given image name. If you believe that this is due to a bug, please report it to info@coguard.io

4) Did you catch how that and my previous note indicated the error being "maximum recursion depth exceeded while calling a Python object"? Of course, a search on that finds discussions on how one can address that via a config setting (in the python app), while others argue that the root cause problem should be resolved. Since both are about thecoguard app (and I don't do coding in Python otherwise myself), I wouldn't fathom to dig in to try to resolve things either way.

Again, that does NOT happen with the hello-world image and only happens with the Tomcat image if the Windows cmd is not "run as admin" before using coguard to scan the tomcat image. I suppose it may have to do with the depth of folders in the image, which perhaps causes the tool to try to extract the folders into some other directory, and that's where the "failed to extract" comes in.

That's what led me to think to try to run the cmd line as admin, which again worked.

5) One quirk, thought: I tried this same approach on another machine (running the cmd prompt as admin, before running coguard), and while I got about 3 of those reported config items and then the 4th was this and following:

Documentation: Tomcat allows deployment of applications upon startup. This can be used by malicious actors to deploy their own applications, and hence should not be allowed. Remediation: For everyHosttag in the server.xmlfile, ensure that the attributedeployOnStartupis set tofalse(default istrue). Source: https://tomcat.apache.org/tomcat-9.0-doc/config/host.html X Severity 5: tomcat_do_not_let_root_start_tomcat Traceback (most recent call last): File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in _run_code exec(code, run_globals) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\Scripts\coguard.exe\__main__.py", line 7, in <module> File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\site-packages\coguard_cli\__main__.py", line 117, in main entrypoint(args) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\site-packages\coguard_cli\__init__.py", line 143, in entrypoint output_result_json_from_coguard(result) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\site-packages\coguard_cli\__init__.py", line 62, in output_result_json_from_coguard print_failed_check(COLOR_RED, entry) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\site-packages\coguard_cli\__init__.py", line 41, in print_failed_check print(wrapper.fill(entry["rule"]["documentation"])) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\textwrap.py", line 371, in fill return "\n".join(self.wrap(text)) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\textwrap.py", line 362, in wrap return self._wrap_chunks(chunks) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\textwrap.py", line 305, in _wrap_chunks self._handle_long_word(chunks, cur_line, cur_len, width) File "C:\Users\careh\AppData\Local\Programs\Python\Python310\lib\textwrap.py", line 223, in _handle_long_word hyphen = chunk.rfind('-', 0, space_left) TypeError: slice indices must be integers or None or have an __index__ method

That's indeed curious that it worked on one machine and not the other. To be clear, I'd installed python and coguard the same way on both (not using an admin cmd line for that). Just clarifying as others may do the same.

Since it works for me on one machine, that's good enough for me. But I share the above in case others may hit and find this, and if you may want to dig further into that. I'm happy to help.

6) Finally FWIW, before trying the "run as admin" I had also realized that I could just shell into the WSL vm, and install python/coguard and run it from there (which is Ubuntu, by default). I did that and it worked, before I thought to try the run as admin.

More than that, if one wants to avoid using the "run as admin" dance, then once they install python and coguard IN the wsl vm, they can even run coguard FROM the windows cmd prompt (even not as admin) but USING wsl with this (which may surprise some):

wsl $HOME/.local/bin/coguard docker-image

I just confirmed that worked find, even for the Tomcat image. But again it won't work if you only install python and coguard in Windows, of course.

7) So to clarify: the problem seems to be with running coguard against some Linux images (like this Tomcat one, but not the hello-world one) at the Windows command line, when running Docker via Docker Desktop, but not running the cmd line "as admin" first. That seems at least worth documenting.

I do realize that some may argue "this is a niche combination we don't need to worry about". I don't think it's really all that niche, but I know many Linux folks would argue vehemently it is, and that Docker Desktop is a crutch/has licensing issues for large orgs, and what-r-you-doing-running-windoze-anyway, etc.

I share all the above to help you and others who may find this. I won't presume for now to propose a PR for the readme, but I can if you want.

8) Oh, one last thing: I had asked how I might know if I'm using that 0.1.15 version, in what I downloaded last night. The debug info also does not show it. But I did find the -v flag (not mentioned on the readme page), and indeed I am running 0.1.15 (now on both Windows and Linux).

Again, documenting these things here in case others may come looking for such info later and find this thread.

Let me know how you think it best to proceed, if anything more at all. :-) Sorry for the long note!

[ioah86]

We really do appreciate the long note.

To your point 5: I noticed that, in a certain version of Python with a certain Terminal, there is an issue with a floating point number we introduced, and fixed yesterday with v 0.1.6

No one holds using Windows against you, do not worry :-) We have seen some issues with Windows, which we are addressing, and they should be fixed in v0.1.17, which we will do next.

Appreciated your efforts, and will have the noted issues ironed out soon.

Best regards,

Albert

[carehart]

Wonderful on all counts, thanks. :-) 

[ioah86]

It turns out that this is an issue with a built-in Python library, and I have filed a bugreport to the Python team about that: https://github.com/python/cpython/issues/95763 In the meantime, we will check if there is a feasible work-around for this.

[carehart]

Wonderful, thanks. There's no urgency. I know you only just added the Tomcat support, so there are likely few "relying" on it yet. And there's that workaround I proposed (of running it via wsl, if one is on Windows) is another solution for those who may hit the issue. :-) Even so, I do hope over time more and more folks using tomcat will learn of and use it. And I look forward to helping spread that news. :-) 

[ioah86]

Following the debugging steps in the Python ticket above, it appears that Windows needs to run in Developer mode (https://docs.microsoft.com/en-us/gaming/game-bar/guide/developer-mode) Given that CoGuard is a developer tool, I do not think having this as a pre-requisite would be infeasible. I tried it on Windows with developer mode on version 0.1.16, and things worked then.

I will update the README.md to reflect this shortly, and then close this ticket, if you are okay with it @carehart

[ioah86]

But please confirm as well

[carehart]

Wow, well, I would counter that while that may be AN option you'd want to propose, it definitely should NOT be the ONLY solution/workaround/recommendation you document for this problem. Why?

Well, I'd share originally that running the cmd prompt "as admin" was indeed ANOTHER option. That's far MORE common/acceptable in my experience. I've been using Windows daily (on several machines for different purposes) and while I run things "as admin" about daily when necessary, I have NEVER used that developer mode.

Indeed, I'd never even HEARD of it until today. :-) And that's saying something, really, as I help people running windows systems daily. (I do server troubleshooting mostly, as well as help people leverage new tools and techniques.) So if I've never come across developer mode, I think I'm pretty representative of a large audience.

So while SOME readers may well prefer the dev mode (if they have experience with it), note that some would like me find that an onerous suggestion. Running "as admin" is temporary, suited to a task like running coguard against an image, while switching to this windows dev mode is a more permanent option with wide-ranging impacts, that may be wholly unacceptable to some--so it could cost you prospective users who hit this and were told to try that

Finally, don't forget a 3rd option I'd mentioned (which I'd list second if I were you): someone could just implement and run coguard within wsl, instead.

I really think the dev mode would be to most an onerous last resort, if it's to be listed at all. The others above make more sense in this situation... and all the more since it's not even ALL images that will suffer the problem.

(I will be surprised if the ultimate root cause in python can't be resolved, but I'd totally understand you're preferring to leave that to them to solve, if perhaps others using it would hit the same problem and press them for that better solution.)

Anyway, you asked. That's my take on your proposal. :-)

[ioah86]

Actually, that is a good idea... Providing alternatives is always better. Thank you for your extremely valuable input!

[carehart]

Very kind of you, thanks. :-)

[ioah86]

Created a Pull Request here: https://github.com/coguardio/coguard-cli/pull/34

[ioah86]

Please review @carehart , and if you have any further input, let me know.

[ioah86]

Just merged the pull request, as no new comments have come in after my last addressing of them. We will close this ticket for now as well, and open up a separate one here once we get to ColdFusion.

Once again, thank you for your input and feedback.