pidgin/nest

Make asset busting depend on deployment environment
default tip
3 weeks ago, Jason Allan
837d728b48d1
Make asset busting depend on deployment environment

At the moment CSS and JS resources have a cache busting tag at the end of their href/src to force a reload when re-rendered. This is deependant on an unused setting, and is present in prod as well, this is really only a feature for development. So, it's been a PITA when diffing outputs

Testing Done:
I've run the `hugo` and `hugo serve` commands with deployment env between prod and dev, and behaviour is as expected

Reviewed at https://reviews.imfreedom.org/r/145/
---
title: Security
type: security
weight: 1000
---
Being a network client which interacts with untrusted users and servers,
managing vulnerabilities and security response is important to the Pidgin
project and to our users. We have established procedures for collecting
security-related information, and for disclosing this information to the
public.
Please see our comprehensive
[list of known and reported security advisories](advisories/) for
information on past vulnerabilities.
## Reporting a Security-related Issue
If you believe you have discovered a security problem or vulnerability in
Pidgin, libpurple, Finch, or one of our related projects, please let us know
by emailing [security@pidgin.im](mailto:security@pidgin.im).
In order to help us fix the problem as quickly as possible and with as little
exposure to malicious intent to our users as can be managed, we ask that you
give us a chance to fix the problem before you publish its existence or details
in a public forum, and that you provide us with as much information as you can.
In return, we will endeavor to respond to your concerns in a timely fashion.
When reporting a security-related bug or a vulnerability, please provide us
with as much of the information in the following list as possible. If you
don't know what something is or how to provide it, that's OK, leave it out and
tell us what you do know.
* A way to contact you or your organization.
* The version of Pidgin, libpurple, Finch, or other package in which the
problem was discovered.
* A concise description of the problem, including a summary of why you believe
it is security-critical. This might be, for example, "Receipt of an invalid
XMPP message containing the tag `<foo>`; causes Pidgin to write data to an
invalid memory location."
* Steps to reproduce the problem, if known.
* Any debugging information, including backtraces (see our instructions for
[obtaining a backtrace](https://developer.pidgin.im/wiki/GetABacktrace), a
debug log (the output of pidgin -d), etc.
* Any proof of concept exploits, debugging tools, or other information you have
and are willing to divulge.
* The oldest and newest versions of our software affected by the bug *to the
best of your knowledge*. If you don't know, that's fine &mdash; we'll try to
find out.
* Information on any security reports or vulnerability assessments you may have
already made on the issue (preferably not yet public, as mentioned above).
* Any proposed embargo dates, release schedules, etc. you or your organization
may have established.
## Receiving Security-related Reports
We maintain a list of packagers and maintainers of Pidgin and related software
which we notify of security vulnerabilities and their fixes prior to disclosure
to the public. This allows packagers and distributors of our software to
release patched or updated versions simultaneously with the public disclosure
of known issues. We attempt to provide sufficient advance warning to this list
that packages may be properly prepared before disclosure.
If you believe you should be on this list, please contact
[security@pidgin.im](mailto:security@pidgin.im) and let us know why.