Prefer SVG format, but allow PNG for logo?

+1 for allowing a logo.svg in the project's Git repository.

One thing that SVG logos would allow us to do is to use CSV variables in the logo. This would allow us to define some standard variables, such as "primaryColor", "secondaryColor", to be provided by the theme. This could allow logos to automatically be recolored to suit the theme. For example the Gin theme has an "accent color" that can be chosen on the settings page. If that could be used within the SVG logos, it could allow logos to adopt a consistent color scheme to suit the chosen theme.

However, I think a first step would be to encourage theme maintainers to put the SVG image in the repos so it can be used in the future. It would be a shame if designers were creating SVG logos, but only the PNG version is saved in the project and the original vector version may not be available if there is a move to SVG images in the future.

SVGs must be sanitized if and only if they're embedded in the HTML using an inline SVG technique. There are no known attack vectors for SVGs that are referenced via <img src="/path/to/file.svg">.

Could we compromise and:

• Support logo.svg by default and fallback to logo.png otherwise.
• Reference SVGs via an IMG tag which doesn't suffer from security issues.
• Create a follow-up issue to migrate to embedded inline SVGs with the aforementioned svg-sanitizer library (github) (packagist). Note: SVG Image → , SVG Image Field → , and SVG Sanitizer → contrib modules all utilize this same library for inlining SVGs.

This would at the very least, get us on the right path towards providing a modern scalable vector graphic for the logo for each project, AND the fact that it is GPLed code committed to the respective project repository means people could easily share/copy ideas since the logos are being designed in vector graphics apps anyway.

These are all excellent points, @jwilson3.

I think most of the logos accepted so far have been created as vector images, so I would love to see the vector files stored somewhere that they are accessible to the community, even if they aren't used for the project cards.

I think one concern for module maintainers would be that SVG logos could be used as a vector to inject malicious code into project repositories, even if there was no way of executing that code. So I think if SVG logos were being used, part of the RTBC process would need to be sanitization, and we would need a tool for checking logos.

SVG logos could be used as a vector to inject malicious code into project repositories, even if there was no way of executing that code. So I think if SVG logos were being used, part of the RTBC process would need to be sanitization, and we would need a tool for checking logos.

The attack vectors (no pun intended) for SVGs are literally the same as for Twig and Javascript (it amounts to being able to execute Javascript).

We currently do not have any automated process for maintainers to review Twig templates and Javascripts for malicious code, so I'm not certain this should be any different. This process is and will always be done via manual reviews. I think this is mostly a non-issue.

// Twig template file:
<script>alert('attack vector')</script>

// Javascript file:
alert('attack vector');

// Inline SVG file:
<script>alert('attack vector')</script>

Back on the topic of using SVGs. I'm not clear if one of the goals of committing SVGs is to be able to alter the colors somehow. But if this is the case, then we probably need to think harder about how this could actually work. All SVGs are not created equal. Some tools put fills/stroke colors in a css classname, others put them in attributes on the PATH tag. All manner of SVG tags can be used. As one example, it would be exceedingly hard to target the square 512x512 background layer without a specific classname to target. We would need a complete set of rules about how the SVG should be written and we'll have to leverage classes and CSS variables to make this all work.

This seems like a fairly complicated problem to solve, because ... well ... contrib. For example, my assumption/understanding is that core modules do not appear in the Project Browser (I could be wrong). Which means that core modules will not have their own logos. Therefore contrib maintainers will be more reluctant to follow logo guidelines if core itself doesn't follow the same rules for its own modules.

My suggestion would be to also push this concept to a follow-up as it complicates things immensely.

We are building on GitLab’s built-in support for project logos. Unless https://gitlab.com/gitlab-org/gitlab/-/issues/13897 lands, we don't have a good way to support SVGs safely.

Left a comment on the upstream outlining some of the same principles from #9.