aeson was vulnerable to hash flooding (a.k.a. hash DoS). The
+issue is a consequence of the HashMap implementation from
+unordered-containers. It results in a denial of service through
+CPU consumption. This technique has been used in real-world attacks
+against a variety of languages, libraries and frameworks over the
+years.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0002.html b/advisory/HSEC-2023-0002.html
new file mode 100644
index 00000000..4efbf247
--- /dev/null
+++ b/advisory/HSEC-2023-0002.html
@@ -0,0 +1,29 @@
+Haskell Security advisories
The Biscuit specification version 1 contains a vulnerable algorithm that allows
+malicious actors to forge valid Γ-signatures. Such an attack would allow an
+attacker to create a token with any access level. The version 2 of the
+specification mandates a different algorithm than gamma signatures and as such
+is not affected by this vulnerability.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0003.html b/advisory/HSEC-2023-0003.html
new file mode 100644
index 00000000..89e04181
--- /dev/null
+++ b/advisory/HSEC-2023-0003.html
@@ -0,0 +1,29 @@
+Haskell Security advisories
The XMonad.Hooks.DynamicLog module in xmonad-contrib before
+0.11.2 allows remote attackers to execute arbitrary commands via a
+web page title, which activates the commands when the user clicks on
+the xmobar window title, as demonstrated using an action tag.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0004.html b/advisory/HSEC-2023-0004.html
new file mode 100644
index 00000000..f2721c44
--- /dev/null
+++ b/advisory/HSEC-2023-0004.html
@@ -0,0 +1,31 @@
+Haskell Security advisories
A vulnerability was found in xml-conduit. It has been classified
+as problematic. Affected is an unknown function of the file
+xml-conduit/src/Text/XML/Stream/Parse.hs of the component DOCTYPE
+Entity Expansion Handler. The manipulation leads to infinite loop.
+It is possible to launch the attack remotely. Upgrading to version
+1.9.1.0 is able to address this issue. The name of the patch is
+4be1021791dcdee8b164d239433a2043dc0939ea. It is recommended to
+upgrade the affected component.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0005.html b/advisory/HSEC-2023-0005.html
new file mode 100644
index 00000000..010e079a
--- /dev/null
+++ b/advisory/HSEC-2023-0005.html
@@ -0,0 +1,32 @@
+Haskell Security advisories
tls-extra: certificate validation does not check Basic Constraints
+
tls-extra does not check the Basic Constraints extension of a
+certificate in certificate chain processing. Any certificate is
+treated as a CA certificate. As a consequence, anyone who has a
+valid certificate can use it to sign another one (with an arbitrary
+subject DN/domain name embedded into it) and have it accepted by
+tls. This allows MITM attacks on TLS connections.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0006.html b/advisory/HSEC-2023-0006.html
new file mode 100644
index 00000000..eff999c0
--- /dev/null
+++ b/advisory/HSEC-2023-0006.html
@@ -0,0 +1,24 @@
+Haskell Security advisories
x509-validation does not enforce pathLenConstraint
+
x509-validation prior to version 1.4.8 did not enforce the
+pathLenConstraint value. Constrained CAs could accidentally (or
+deliberately) issue CAs below the maximum depth and
+x509-validation would accept certificates issued by the
+unauthorised intermediate CAs.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0007.html b/advisory/HSEC-2023-0007.html
new file mode 100644
index 00000000..79a101a7
--- /dev/null
+++ b/advisory/HSEC-2023-0007.html
@@ -0,0 +1,65 @@
+Haskell Security advisories
[advisory]
+id = "HSEC-2023-0007"
+cwe = [1284, 789]
+keywords = ["toml", "parser", "dos"]
+
+[[affected]]
+package = "base"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+[[affected.versions]]
+# it was introduced earlier, but this is the earliest version on Hackage
+introduced = "3.0.3.1"
+
+[[affected]]
+package = "toml-reader"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.2.0.0"
+
+[[references]]
+type = "REPORT"
+url = "https://gitlab.haskell.org/ghc/ghc/-/issues/23538"
+[[references]]
+type = "REPORT"
+url = "https://github.com/brandonchinn178/toml-reader/issues/8"
+[[references]]
+type = "FIX"
+url = "https://github.com/brandonchinn178/toml-reader/pull/9"
+
+
+
readFloat: memory exhaustion with large exponent
+
Numeric.readFloat takes time and memory linear in the size of the
+number denoted by the input string. In particular, processing a
+number expressed in scientific notation with a very large exponent
+could cause a denial of service. The slowdown is observable on a
+modern machine running GHC 9.4.4:
Numeric.readFloat is defined for all RealFrac a => a:
+
readFloat :: RealFrac a => ReadS a
+
+
The RealFrac type class does not express any bounds on the size of
+values representable in the types for which instances exist, so
+bounds checking is not possible (in this generic function).
+readFloat uses to Text.Read.Lex.numberToRational which, among
+other things, calculates 10 ^ exponent, which seems to take linear
+time and memory.
+
Mitigation: use read. The Read instances for Float and
+Double perform bounds checks on the exponent, via
+Text.Read.Lex.numberToRangedRational.
+
In toml-reader
+
The issue was detected in toml-reader version 0.1.0.0, and
+mitigated in version 0.2.0.0 by immediately returning Infinity
+when the exponent is large enough that there's no reason to process
+it.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0008.html b/advisory/HSEC-2023-0008.html
new file mode 100644
index 00000000..c11719e7
--- /dev/null
+++ b/advisory/HSEC-2023-0008.html
@@ -0,0 +1,41 @@
+Haskell Security advisories
An issue was discovered in hledger-web < 1.23. A Stored Cross-Site
+Scripting (XSS) vulnerability exists in toBloodhoundJson that
+allows an attacker to execute JavaScript by encoding user-controlled
+values in a payload with base64 and parsing them with the atob
+function.
+
hledger-web forms sanitise obvious JavaScript, but not obfuscated
+JavaScript (see OWASP Filter Evasion Cheat Sheet).
+This means hledger-web instances, especially anonymously-writable
+ones like demo.hledger.org, could be loaded with malicious
+JavaScript to be executed by subsequent visitors.
+
Reported by Gaspard Baye and Hamidullah Muslih. Fix by Arsen
+Arsenović.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0009.html b/advisory/HSEC-2023-0009.html
new file mode 100644
index 00000000..0c42d2cc
--- /dev/null
+++ b/advisory/HSEC-2023-0009.html
@@ -0,0 +1,40 @@
+Haskell Security advisories
git-annex command injection via malicious SSH hostname
+
git-annex was vulnerable to the same class of security hole as
+git's CVE-2017-1000117. In several cases, git-annex parses a
+repository URL, and uses it to generate a ssh command, with the
+hostname to ssh to coming from the URL. If the hostname it parses is
+something like -eProxyCommand=evil, this could result in arbitrary
+local code execution.
+
Some details of URL parsing may prevent the exploit working in some
+cases.
+
Exploiting this would involve the attacker tricking the victim into
+adding a remote something like ssh://-eProxyCommand=evil/blah.
+
One possible avenue for an attacker that avoids exposing the URL to
+the user is to use initremote with an SSH remote, so embedding the
+URL in the git-annex branch. Then the victim would enable it with
+enableremote.
+
This was fixed in version 6.20170818. Now there's a SshHost
+type that is not allowed to start with a dash, and every invocation
+of git-annex uses a function that takes a SshHost.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0010.html b/advisory/HSEC-2023-0010.html
new file mode 100644
index 00000000..8ae91018
--- /dev/null
+++ b/advisory/HSEC-2023-0010.html
@@ -0,0 +1,64 @@
+Haskell Security advisories
git-annex private data exfiltration to compromised remote
+
Some uses of git-annex were vulnerable to a private data exposure
+and exfiltration attack. It could expose the content of files
+located outside the git-annex repository, or content from a
+private web server on localhost or the LAN. Joey Hess discovered
+this attack.
+
To perform this attack, the attacker needs to have control over one
+of the remotes of the victim's git-annex repository. For example,
+they may provide a public git-annex repository that the victim
+clones. Or, equivalantly, the attacker could have read access to the
+victim's git-annex repository or a repository it pushes to, and
+some channel to get commits into it (e.g. pull requests).
+
These exploits are most likely to succeed when the victim is running
+the git-annex assistant, or is periodically running git annex sync --content.
+
To perform the attack the attacker runs git-annex addurl --relaxed file:///etc/passwd and commits this to the repository in some out
+of the way place. After the victim's git repository receives that
+change, git-annex follows the attacker-provided URL to the private
+data, which it stores in the git-annex repository. From there it
+transfers the content to the remote git-annex repository that the
+attacker has access to.
+
As well as file:/// URLs, the attacker can use URLs to private web
+servers. The URL can also be one that the attacker controls, that
+redirects to a URL that is accessible to the victim system (and not
+necessarily the compromised remote).
+
Fix
+
The issue was fixed by making git-annex refuse to follow
+file:/// urls and URLs pointing to private/local IP addresses by
+default. Two new configuration settings,
+annex.security.allowed-url-schemes and
+annex.security.allowed-ip-addresses, can relax this security
+policy, and are intended for cases where the git-annex repository
+is kept private and so the attack does not apply.
+
Impact on external special remotes
+
One variant of this issue can exploit a vulnerable external special
+remote, and could not be prevented by git-annex. (git-annex's
+own built-in special remotes are not vulnerable to this attack.)
+
In this attack variant, the attacker guesses the hash of a file
+stored on the victim's private web server, and adds it to the
+git-annex repository. The attacker also has control of the server
+hosting an encrypted special remote used by the victim's git-annex
+repository. They cause that server to redirect to the victim's web
+server. This allows the attacker to verify if the victim's web
+server contains a file that the attacker already knows the content
+of, assuming they can guess the URL to it.
+
Developers of external special remotes are encouraged to prevent
+this attack by not following such HTTP redirects.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0011.html b/advisory/HSEC-2023-0011.html
new file mode 100644
index 00000000..10bf17ab
--- /dev/null
+++ b/advisory/HSEC-2023-0011.html
@@ -0,0 +1,42 @@
+Haskell Security advisories
git-annex GPG decryption attack via compromised remote
+
A malicious server for a special remote could trick git-annex into
+decrypting a file that was encrypted to the user's GPG key. This
+attack could be used to expose encrypted data that was never stored
+in git-annex. Daniel Dent discovered this attack in collaboration
+with Joey Hess.
+
To perform this attack the attacker needs control of a server
+hosting an encrypted special remote used by the victim's
+git-annex repository. The attacker uses git annex addurl --relaxed with an innocuous URL, and waits for the user's
+git-annex to download it, and upload an (encrypted) copy to the
+special remote they also control. At some later point, when the
+user downloads the content from the special remote, the attacker
+instead sends them the content of the GPG-encrypted file that they
+wish to have decrypted in its place (which may have been exfiltrated
+from the victim's system via the attack described in
+HSEC-2023-0010 / CVE-2018-10857, or acquired by other
+means). Finally, the attacker drops their own copy of the original
+innocuous URL, and waits for the victim git-annex to send them the
+accidentially decrypted file.
+
The issue was fixed by making git-annex refuse to download
+encrypted content from special remotes, unless it knows the hash of
+the expected content. When the attacker provides some other
+GPG-encrypted content, it will fail the hash check and be discarded.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0012.html b/advisory/HSEC-2023-0012.html
new file mode 100644
index 00000000..accca5ae
--- /dev/null
+++ b/advisory/HSEC-2023-0012.html
@@ -0,0 +1,29 @@
+Haskell Security advisories
git-annex checksum exposure to encrypted special remotes
+
A bug exposed the checksum of annexed files to encrypted special
+remotes, which are not supposed to have access to the checksum of
+the un-encrypted file. This only occurred when resuming uploads to
+the encrypted special remote, so it is considered a low-severity
+security hole.
+
For details, see commit b890f3a53d936b5e40aa9acc5876cb98f18b9657.
+
No CVE was assigned for this issue.
+
Fixed in git-annex-6.20160419.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0013.html b/advisory/HSEC-2023-0013.html
new file mode 100644
index 00000000..88618a87
--- /dev/null
+++ b/advisory/HSEC-2023-0013.html
@@ -0,0 +1,64 @@
+Haskell Security advisories
git-annex plaintext storage of embedded credentials on encrypted remotes
+
git-annex had a bug in the S3 and Glacier remotes where if
+embedcreds=yes was set, and the remote used encryption=pubkey or
+encryption=hybrid, the embedded AWS credentials were stored in the
+Git repository in (effectively) plaintext, not encrypted as they
+were supposed to be.
+
That means that anyone who gets a copy of the Git repository can
+extract the AWS credentials from it. Which would be bad.
+
A remote with this problem cannot be enabled using git annex enableremote. Old versions of git-annex will fail with a GPG
+error; the current version will fail with a pointer to this web
+page.
+
Remediation
+
If your repository has this problem, chose from one of these
+approaches to deal with it:
+
+
+
Change your AWS credentials, so the ones stored in the clear in
+git won't be used.
+
After changing the credentials, make sure you have a fixed
+version of git-annex, and you can then re-embed the new creds
+into the repository, encrypted this time, by setting the
+AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID environment
+variables, and running git annex enableremote $remotename embedcreds=yes.
+
+
+
Fix the problem and then remove the history of the git-annex
+branch of the repository.
+
Make sure you have a fixed version of git-annex, and force
+git-annex to rewrite the embedded creds, with encryption this
+time, by setting by setting the AWS_SECRET_ACCESS_KEY and
+AWS_ACCESS_KEY_ID environment variables, and running git annex enableremote $remotename embedcreds=yes.
+
Then, to get rid of old versions of the git-annex branch that
+still contains the creds in cleartext, you can use git annex forget; note that it will remove other historical data too.
+
Keep in mind that this will not necessarily delete data from
+clones you do not control.
+
+
+
If you're sure that you're the only one who has access to the
+repository, you could decide to leave it as-is. It's no more
+insecure than if you had used encryption=shared in the first
+place when setting it up.
+
+
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0014.html b/advisory/HSEC-2023-0014.html
new file mode 100644
index 00000000..dff190eb
--- /dev/null
+++ b/advisory/HSEC-2023-0014.html
@@ -0,0 +1,24 @@
+Haskell Security advisories
Arbitrary file write is possible when using PDF output or --extract-media with untrusted input
+
Pandoc is susceptible to an arbitrary file write vulnerability, which can be triggered by providing a specially crafted image element in the input when generating files using the --extract-media option or outputting to PDF format. This vulnerability allows an attacker to create or overwrite arbitrary files on the system (depending on the privileges of the process running pandoc).
+
This vulnerability only affects systems that (a) pass untrusted user input to pandoc and (b) allow pandoc to be used to produce a PDF or with the --extract-media option.
+
The vulnerability is patched in pandoc 3.1.4.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2023-0015.html b/advisory/HSEC-2023-0015.html
new file mode 100644
index 00000000..a807bef2
--- /dev/null
+++ b/advisory/HSEC-2023-0015.html
@@ -0,0 +1,87 @@
+Haskell Security advisories
A problem was recently discovered in cabal-install's
+implementation of the Hackage Security protocol that would allow an
+attacker who was in possession of a revoked private key and who
+could perform a man-in-the-middle attack against Hackage to use the
+revoked key to deliver malicious packages. At this time, this is
+only a theoretical attack - no keys have been revoked. Release
+3.10.2.0 of cabal-install contains a fix for this bug, and we have
+contacted distributors of older versions (such as Linux
+distributions) with a patch that they can apply.
+
Background
+
Hackage Security is an implementation of The Update Framework,
+which is a design for a package repository that allows untrusted
+mirrors without undermining software supply-chain security. In
+particular, Hackage Security cryptographically guarantees the
+following properties:
+
+
+
Mirrors of Hackage cannot change the contents of packages. This
+prevents the insertion of malicious code.
+
+
+
Mirrors cannot omit newer packages for more than a few days
+without clients noticing. This ensures both that mirrors cannot
+maliciously deny security updates, and that mistakes in their
+configuration will be noticed.
+
+
+
Hackage has a key policy file that delegates authority to a
+number of private keys for various purposes. Most of the keys are
+kept securely offline by trusted community members who annually
+re-sign the various files to indicate that they still have
+confidence in Hackage's policies. However, to prevent clients from
+being denied updates, Hackage has an automated process that
+periodically re-signs a timestamp file. This signature has a short
+expiry. Additionally, a snapshot file contains signed hashes of the
+Hackage index that is updated on each package upload. The timestamp
+and snapshot private keys are held in memory on the Hackage server.
+These are called the operational keys. If an operational key is ever
+compromised, then it will be revoked by having the Hackage root
+keyholders sign a new key policy file. To prevent replay attacks,
+clients that connect to Hackage after this update will reject older
+policy files, based on a monotonically increasing file version
+number.
+
If a client has not yet received the updated policy file (for
+example, because they have a fresh install of cabal-install or
+because they have not run cabal update in some time), the built-in
+expiration date in the file limits the window of exposure in which
+the revoked operational keys would be expected. As long as the root
+keys have not been compromised, the compromised operational keys can
+only be used until the policy file expires. In addition to
+compromising a Hackage operational key, an attacker would
+additionally need to either compromise a Hackage mirror or perform a
+man-in-the-middle attack against the target in order to serve a
+malicious or obsolete package index.
+
The Issue
+
A bug in cabal-install caused it to skip the verification of the
+key policy file's expiration timestamp. This means that users of
+older, unpatched versions of cabal-install could be vulnerable to
+a malicious mirror or man-in-the-middle attack against Hackage if
+they have not connected to Hackage in a long time, even after the
+policy file has expired.
+
We do not believe that it has been possible to exploit this
+vulnerability, because no operational keys have been revoked.
+However, in case key revocation occurs, we strongly advise all users
+of cabal-install to ensure that they have version 3.10.2.0 or
+newer, which contain the fix.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2024-0001.html b/advisory/HSEC-2024-0001.html
new file mode 100644
index 00000000..36b29ac1
--- /dev/null
+++ b/advisory/HSEC-2024-0001.html
@@ -0,0 +1,27 @@
+Haskell Security advisories
Keter is an app-server/reverse-proxy often used with webapps build on Yesod web-framework.
+
In the logic handling VHost dispatch, Keter was echoing back Host header value, unescaped,
+as part of an HTML error page. This constitutes a reflected-XSS vulnerability. Although
+not readily exploitable directly from a browser (where Host header can't generally assume
+arbitrary values), it may become such in presence of further weaknesses in components
+upstream of Keter in the http proxying chain. Therefore, AC:High in CVSS evaluation.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2024-0002.html b/advisory/HSEC-2024-0002.html
new file mode 100644
index 00000000..4b552071
--- /dev/null
+++ b/advisory/HSEC-2024-0002.html
@@ -0,0 +1,57 @@
+Haskell Security advisories
out-of-bounds write when there are many bzip2 selectors
+
A malicious bzip2 payload may produce a memory corruption
+resulting in a denial of service and/or remote code execution.
+Network services or command line utilities decompressing
+untrusted bzip2 payloads are affected.
+
Note that the exploitation of this bug relies on an undefined
+behavior that appears to be handled safely by current compilers.
+
The Haskell libraires are vulnerable when they are built using
+the bundled C library source code, which is the default
+in most cases.
+
\ No newline at end of file
diff --git a/advisory/HSEC-2024-0003.html b/advisory/HSEC-2024-0003.html
new file mode 100644
index 00000000..b3b4287b
--- /dev/null
+++ b/advisory/HSEC-2024-0003.html
@@ -0,0 +1,127 @@
+Haskell Security advisories
process: command injection via argument list on Windows
+
The process library on Windows is vulnerable to a command injection
+vulnerability, via cmd.exe's interpretation of arguments. Programs that
+invoke batch files (.bat, .cmd) and pass arguments whose values are
+affected by program inputs may be affected.
+
This issue was discovered in many programming languages' Windows process
+execution behaviour. It was tracked by CERT/CC as VU#123335 and a
+coordinated disclosure was made on 2024-04-09 17:00 UTC.
+
A fix was released in process-1.6.19.0.
+
Background
+
Unlike POSIX systems, Windows does not have a mechanism for passing multiple
+arguments.Command line parsing is up to individual programs.
+
The process library defines the RawCommand constructor for specifying an
+executable and its arguments:
On Windows, the RawCommand executable name and arguments are serialised into
+a single command line string, with separate arguments quoted separately.
+process then invokes the Windows CreateProcess
+routine with this command line string is given as the lpCommandLine
+argument.
+
Issue
+
When executing .bat or .cmd files, CreateProcess
+implicitly spawns cmd.exe. The System.Process command line construction
+does not escape characters with special meaning to cmd.exe. As a
+consequence, a command injection vulnerability arises when the following
+conditions are satisfied:
+
+
Program running on Windows
+
+
Program executes a .bat or .cmd file
+
+
The argument values include or are influenced by program input
+
+
+
Demonstration
+
The following batch file, test.bat, merely prints the executable name the
+first two arguments (as interpreted by cmd.exe):
In addition to producing the above output, calc.exe is executed.
+
Mitigation
+
The lack of a general mechanism on Windows for safely conveying command line
+arguments to programs increases the risk of this kind of security issue. The
+fact that cmd.exe command line parsing is complex and poorly documented
+exacerbates this issue, and also heightens the risk that the fix is
+incomplete, or causes other issues.
+
If possible, avoid executing batch files where arguments include or are
+influenced by untrusted program inputs. If it must be done, reject arguments
+that include special characters including & and ".
+
Fix versions
+
process was modified to perform additional escaping and quoting
+when executing .bat and .cmd files on Windows (ignoring
+character case). The behaviour is unchanged in all other cases.
+
The fix was released in process-1.6.19.0. The following GHC
+releases were the first in their series to include a fixed version
+of the process library:
+
+
GHC 9.10.1-alpha3 (released 2024-04-15)
+
+
GHC 9.8.x (no release with fix yet)
+
+
GHC 9.6.5 (released 2024-04-16)
+
+
+
Such a change in semantics should normally result in a major version
+bump. Because we expect very few (if any) users will be impacted by
+the behavioural change, the GHC team made a pragmatic decision to
+avoid the disruption that a major version bump would cause.
+
Acknowledgements
+
Security researcher RyotaK discovered and responsibly disclosed
+this vulnerability, coordinating the response across the many
+affected langauges and ecosystems.
+
Ben Gamari commited and released the fix, which was based on a
+proposal by Fraser Tweedale. Fraser also improved the
+System.Process module documentation to better explain the Windows
+semantics.
+
\ No newline at end of file
diff --git a/assets/css/default.css b/assets/css/default.css
new file mode 100644
index 00000000..17973558
--- /dev/null
+++ b/assets/css/default.css
@@ -0,0 +1,152 @@
+:root{
+ --bg-color:#FFFFFF;
+ --text-color:#333;
+ --outline-color:#DB83ED;
+ --header-color:#5E5184;
+ --anchor-color:#9E358F;
+ --anchor-visited-color:#6F5F9C;
+ --code-bg-color:#FAFAFA;
+ --filename-bg:#EAEAEA;
+ --code-color:#383a42;
+ --code-bg-color:#fafafa;
+ --code-comment-color:#a0a1a7;
+ --code-kw-color:#af005f;
+ --code-name-color:#e45649;
+ --code-literal-color:#268bd2;
+ --code-string-color:#cb4b16;
+ --code-attr-color:#986801;
+ --code-constructor-color:#5f5faf;
+ --code-symbol-color:#4078f2;
+ --code-record-field-color:#c18401;
+ --code-pragma-color:#2aa198
+}
+@media (prefers-color-scheme:dark){
+ :root{
+ --bg-color:#333;
+ --text-color:#C9D1D9;
+ --header-color:#BBA1FF;
+ --anchor-color:#EB82DC;
+ --anchor-visited-color:#D5C5FF;
+ --code-bg-color:transparent;
+ --filename-bg:#2C2C2C;
+ --code-color:#C9D1D9;
+ --code-bg-color:#333;
+ --code-comment-color:#a0a1a7;
+ --code-kw-color:#BBA1FF;
+ --code-name-color:#e45649;
+ --code-literal-color:#268bd2;
+ --code-string-color:#cb4b16;
+ --code-attr-color:#986801;
+ --code-constructor-color:#d079c9;
+ --code-symbol-color:var(--code-color);
+ --code-record-field-color:#c18401;
+ --code-pragma-color:#2aa198
+ }
+}
+*:focus-visible{
+ outline-color:var(--outline-color)
+}
+body{
+ color:var(--text-color);
+ background-color:var(--bg-color)
+}
+a{
+ color:var(--anchor-color)
+}
+a:visited{
+ color:var(--anchor-visited-color)
+}
+h1,h2,h3,h4,h5,h6{
+ color:var(--header-color)
+}
+input{
+ background-color:rgba(255,255,255,0.06);
+ color:var(--text-color)
+}
+.nav-bar{
+ text-align: right;
+}
+.nav-bar ul{
+ display: inline-block;
+ list-style: none;
+ margin: 0;
+ padding: 0;
+}
+.nav-bar li{
+ display: inline-block;
+ vertical-align: middle;
+ padding: 0;
+ margin: 0;
+ height: 100%;
+ position: relative;
+}
+ *:focus-visible{
+ outline-offset:4px;
+ outline-width:1px
+}
+body{
+ font-size:1.6rem;
+ margin:0 auto;
+ max-width:120rem
+}
+footer{
+ margin-top:3rem;
+ padding:1.2rem 0;
+ border-top:0.2rem solid #000;
+ font-size:1.2rem;
+ color:#555
+}
+h1{
+ font-size:2.4rem
+}
+h2{
+ font-size:2rem
+}
+html{
+ font-size:62.5%;
+ font-family:Helvetica,sans-serif
+}
+table tbody td{
+ padding:5px
+}
+footer{
+ padding: 0 2%;
+ text-align: center;
+}
+footer .HF{
+ height:50px;
+ line-height:50px;
+ display:inline-block;
+ background-repeat:no-repeat;
+ background-image:url('../images/hf-logo.png');
+ background-size:50px;
+ background-position:left center;
+ padding-left:60px
+}
+@media (max-width:319px){
+ .nav-bar{
+ margin:0 1.5rem 0 0;
+ }
+ .nav-bar a{
+ display:block;
+ line-height:1.6
+ }
+}
+@media (min-width:320px){
+ .nav-bar{
+ margin:0 2rem 0 0;
+ }
+ .nav-bar a{
+ display:inline;
+ margin:0 0.6rem
+ }
+}
+@media (min-width:640px){
+ .nav-bar{
+ margin:0 3rem 0 0;
+ }
+ .nav-bar a{
+ margin:0 0 0 1.2rem;
+ display:inline
+ }
+}
diff --git a/assets/images/hf-logo.png b/assets/images/hf-logo.png
new file mode 100644
index 00000000..5a79f4c1
Binary files /dev/null and b/assets/images/hf-logo.png differ
diff --git a/atom.xml b/atom.xml
new file mode 100644
index 00000000..b396361c
--- /dev/null
+++ b/atom.xml
@@ -0,0 +1,827 @@
+Haskell Security Advisory DBhttps://haskell.github.io/security-advisories/atom.xml2024-04-09T22:14:47ZHaskell Security Response Teamhttps://haskell.github.io/security-advisories/advisory/HSEC-2023-0008.htmlHSEC-2023-0008 - Stored XSS in hledger-web2023-07-22T12:23:10Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0008"
+cwe = [87]
+keywords = ["web", "xss", "historical"]
+aliases = ["CVE-2021-46888"]
+
+[[affected]]
+package = "hledger-web"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N"
+[[affected.versions]]
+introduced = "0.24"
+fixed = "1.23"
+
+[[references]]
+type = "REPORT"
+url = "https://github.com/simonmichael/hledger/issues/1525"
+[[references]]
+type = "INTRODUCED"
+url = "https://github.com/simonmichael/hledger/commit/ec51d28839b2910eea360b1b8c72904b51cf7821"
+[[references]]
+type = "EVIDENCE"
+url = "https://www.youtube.com/watch?v=QnRO-VkfIic"
+[[references]]
+type = "FIX"
+url = "https://github.com/simonmichael/hledger/pull/1663"
+
+</code></pre>
+<h1>Stored XSS in <em>hledger-web</em></h1>
+<p>An issue was discovered in <em>hledger-web</em> < 1.23. A Stored Cross-Site
+Scripting (XSS) vulnerability exists in <code>toBloodhoundJson</code> that
+allows an attacker to execute JavaScript by encoding user-controlled
+values in a payload with base64 and parsing them with the <code>atob</code>
+function.</p>
+<p><em>hledger-web</em> forms sanitise obvious JavaScript, but not obfuscated
+JavaScript (see <a href="https://owasp.org/www-community/xss-filter-evasion-cheatsheet">OWASP Filter Evasion Cheat Sheet</a>).
+This means <em>hledger-web</em> instances, especially anonymously-writable
+ones like <code>demo.hledger.org</code>, could be loaded with malicious
+JavaScript to be executed by subsequent visitors.</p>
+<p>Reported by Gaspard Baye and Hamidullah Muslih. Fix by Arsen
+Arsenović.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0014.htmlHSEC-2023-0014 - Arbitrary file write is possible when using PDF output or --extract-media with untrusted input2023-08-22T23:08:06Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0014"
+keywords = ["file write"]
+aliases = ["CVE-2023-35936", "GHSA-xj5q-fv23-575g"]
+cwe = [20]
+
+[[references]]
+type = "REPORT"
+url = "https://github.com/jgm/pandoc/security/advisories/GHSA-xj5q-fv23-575g"
+
+[[affected]]
+package = "pandoc"
+cvss = "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:L"
+
+[[affected.versions]]
+introduced = "1.13"
+fixed = "3.1.4"
+
+</code></pre>
+<h1>Arbitrary file write is possible when using PDF output or --extract-media with untrusted input</h1>
+<p>Pandoc is susceptible to an arbitrary file write vulnerability, which can be triggered by providing a specially crafted image element in the input when generating files using the --extract-media option or outputting to PDF format. This vulnerability allows an attacker to create or overwrite arbitrary files on the system (depending on the privileges of the process running pandoc).</p>
+<p>This vulnerability only affects systems that (a) pass untrusted user input to pandoc and (b) allow pandoc to be used to produce a PDF or with the --extract-media option.</p>
+<p>The vulnerability is patched in pandoc 3.1.4.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0005.htmlHSEC-2023-0005 - tls-extra: certificate validation does not check Basic Constraints2023-07-19T13:29:39Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0005"
+cwe = [295]
+keywords = ["x509", "pki", "mitm", "historical"]
+aliases = ["CVE-2013-0243"]
+
+[[affected]]
+package = "tls-extra"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
+
+[[affected.versions]]
+introduced = "0.1.0"
+fixed = "0.4.6.1"
+
+[[references]]
+type = "DISCUSSION"
+url = "https://www.openwall.com/lists/oss-security/2013/01/30/6"
+[[references]]
+type = "REPORT"
+url = "https://github.com/haskell-tls/hs-tls/issues/29"
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell-tls/hs-tls/commit/15885c0649ceabd2f4d2913df8ac6dc63d6b3b37"
+</code></pre>
+<h1>tls-extra: certificate validation does not check Basic Constraints</h1>
+<p><em>tls-extra</em> does not check the Basic Constraints extension of a
+certificate in certificate chain processing. Any certificate is
+treated as a CA certificate. As a consequence, anyone who has a
+valid certificate can use it to sign another one (with an arbitrary
+subject DN/domain name embedded into it) and have it accepted by
+<em>tls</em>. This allows MITM attacks on TLS connections.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0006.htmlHSEC-2023-0006 - x509-validation does not enforce pathLenConstraint2023-07-19T13:59:54Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0006"
+cwe = [295]
+keywords = ["x509", "pki", "historical"]
+
+[[affected]]
+package = "x509-validation"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N"
+
+[[affected.versions]]
+introduced = "1.4.0"
+fixed = "1.4.8"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell-tls/hs-certificate/commit/06d15dbbc53739314760d8504ca764000770e46e"
+</code></pre>
+<h1>x509-validation does not enforce pathLenConstraint</h1>
+<p><em>x509-validation</em> prior to version 1.4.8 did not enforce the
+pathLenConstraint value. Constrained CAs could accidentally (or
+deliberately) issue CAs below the maximum depth and
+<em>x509-validation</em> would accept certificates issued by the
+unauthorised intermediate CAs.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2024-0001.htmlHSEC-2024-0001 - Reflected XSS vulnerability in keter2024-02-27T17:06:24Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2024-0001"
+cwe = [79]
+keywords = ["http", "xss", "rxss", "historic"]
+
+[[references]]
+type = "FIX"
+url = "https://github.com/snoyberg/keter/pull/246"
+
+[[affected]]
+package = "keter"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N"
+declarations."Keter.Proxy.toResponse" = ">= 0.3.4 && < 1.0.1"
+declarations."Keter.Proxy.unknownHostResponse" = ">= 1.0.1 && < 1.8.4"
+
+[[affected.versions]]
+introduced = "0.3.4"
+fixed = "1.8.4"
+</code></pre>
+<h1>Reflected XSS vulnerability in keter</h1>
+<p>Keter is an app-server/reverse-proxy often used with webapps build on Yesod web-framework.</p>
+<p>In the logic handling VHost dispatch, Keter was echoing back <code>Host</code> header value, unescaped,
+as part of an HTML error page. This constitutes a reflected-XSS vulnerability. Although
+not readily exploitable directly from a browser (where <code>Host</code> header can't generally assume
+arbitrary values), it may become such in presence of further weaknesses in components
+upstream of Keter in the http proxying chain. Therefore, AC:High in CVSS evaluation.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0015.htmlHSEC-2023-0015 - cabal-install uses expired key policies2023-11-07T03:57:00Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0015"
+cwe = [672]
+keywords = ["hackage", "mitm", "supply-chain"]
+
+[[affected]]
+package = "cabal-install"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N"
+[[affected.versions]]
+introduced = "1.24.0.0"
+fixed = "3.10.2.0"
+
+[[references]]
+type = "REPORT"
+url = "https://github.com/haskell/cabal/issues/8918#issuecomment-1521096581"
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell/cabal/commit/dcfdc9cffd74cade4e8cf3df37c5993413ffd30f"
+</code></pre>
+<h1>cabal-install uses expired key policies</h1>
+<p>A problem was recently discovered in <code>cabal-install</code>'s
+implementation of the Hackage Security protocol that would allow an
+attacker who was in possession of a revoked private key and who
+could perform a man-in-the-middle attack against Hackage to use the
+revoked key to deliver malicious packages. At this time, this is
+only a theoretical attack - no keys have been revoked. Release
+3.10.2.0 of <code>cabal-install</code> contains a fix for this bug, and we have
+contacted distributors of older versions (such as Linux
+distributions) with a patch that they can apply.</p>
+<h2>Background</h2>
+<p>Hackage Security is an implementation of <a href="https://theupdateframework.io/">The Update Framework</a>,
+which is a design for a package repository that allows untrusted
+mirrors without undermining software supply-chain security. In
+particular, Hackage Security cryptographically guarantees the
+following properties:</p>
+<ul>
+<li>
+<p>Mirrors of Hackage cannot change the contents of packages. This
+prevents the insertion of malicious code.</p>
+</li>
+<li>
+<p>Mirrors cannot omit newer packages for more than a few days
+without clients noticing. This ensures both that mirrors cannot
+maliciously deny security updates, and that mistakes in their
+configuration will be noticed.</p>
+</li>
+</ul>
+<p>Hackage has a <a href="https://hackage.haskell.org/root.json">key policy file</a> that delegates authority to a
+number of private keys for various purposes. Most of the keys are
+kept securely offline by trusted community members who annually
+re-sign the various files to indicate that they still have
+confidence in Hackage's policies. However, to prevent clients from
+being denied updates, Hackage has an automated process that
+periodically re-signs a timestamp file. This signature has a short
+expiry. Additionally, a snapshot file contains signed hashes of the
+Hackage index that is updated on each package upload. The timestamp
+and snapshot private keys are held in memory on the Hackage server.
+These are called the operational keys. If an operational key is ever
+compromised, then it will be revoked by having the Hackage root
+keyholders sign a new key policy file. To prevent replay attacks,
+clients that connect to Hackage after this update will reject older
+policy files, based on a monotonically increasing file version
+number.</p>
+<p>If a client has not yet received the updated policy file (for
+example, because they have a fresh install of <code>cabal-install</code> or
+because they have not run <code>cabal update</code> in some time), the built-in
+expiration date in the file limits the window of exposure in which
+the revoked operational keys would be expected. As long as the root
+keys have not been compromised, the compromised operational keys can
+only be used until the policy file expires. In addition to
+compromising a Hackage operational key, an attacker would
+additionally need to either compromise a Hackage mirror or perform a
+man-in-the-middle attack against the target in order to serve a
+malicious or obsolete package index.</p>
+<h2>The Issue</h2>
+<p>A bug in <code>cabal-install</code> caused it to skip the verification of the
+key policy file's expiration timestamp. This means that users of
+older, unpatched versions of <code>cabal-install</code> could be vulnerable to
+a malicious mirror or man-in-the-middle attack against Hackage if
+they have not connected to Hackage in a long time, even after the
+policy file has expired.</p>
+<p>We do not believe that it has been possible to exploit this
+vulnerability, because no operational keys have been revoked.
+However, in case key revocation occurs, we strongly advise all users
+of <code>cabal-install</code> to ensure that they have version 3.10.2.0 or
+newer, which contain the fix.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0004.htmlHSEC-2023-0004 - xml-conduit unbounded entity expansion2023-07-18T14:37:41Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0004"
+cwe = [776]
+keywords = ["xml", "dos", "historical"]
+aliases = ["CVE-2021-4249", "VDB-216204"]
+
+[[affected]]
+package = "xml-conduit"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+
+[[affected.versions]]
+introduced = "0.5.0"
+fixed = "1.9.1.0"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/snoyberg/xml/pull/161"
+[[references]]
+type = "FIX"
+url = "https://github.com/snoyberg/xml/commit/4be1021791dcdee8b164d239433a2043dc0939ea"
+</code></pre>
+<h1>xml-conduit unbounded entity expansion</h1>
+<p>A vulnerability was found in <em>xml-conduit</em>. It has been classified
+as problematic. Affected is an unknown function of the file
+<code>xml-conduit/src/Text/XML/Stream/Parse.hs</code> of the component DOCTYPE
+Entity Expansion Handler. The manipulation leads to infinite loop.
+It is possible to launch the attack remotely. Upgrading to version
+1.9.1.0 is able to address this issue. The name of the patch is
+<code>4be1021791dcdee8b164d239433a2043dc0939ea</code>. It is recommended to
+upgrade the affected component.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0003.htmlHSEC-2023-0003 - code injection in xmonad-contrib2023-06-19T21:35:14Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0003"
+cwe = [94]
+keywords = ["code", "injection", "historical"]
+aliases = ["CVE-2013-1436"]
+
+[[affected]]
+package = "xmonad-contrib"
+cvss = "AV:N/AC:L/Au:N/C:P/I:P/A:P"
+[[affected.versions]]
+introduced = "0.5"
+fixed = "0.11.2"
+
+[[references]]
+type = "ADVISORY"
+url = "https://security.gentoo.org/glsa/201405-28"
+[[references]]
+type = "DISCUSSION"
+url = "http://www.openwall.com/lists/oss-security/2013/07/26/5"
+[[references]]
+type = "FIX"
+url = "https://github.com/xmonad/xmonad-contrib/commit/d3b2a01e3d01ac628e7a3139dd55becbfa37cf51"
+</code></pre>
+<h1>code injection in <em>xmonad-contrib</em></h1>
+<p>The <code>XMonad.Hooks.DynamicLog</code> module in <em>xmonad-contrib</em> before
+<strong>0.11.2</strong> allows remote attackers to execute arbitrary commands via a
+web page title, which activates the commands when the user clicks on
+the xmobar window title, as demonstrated using an action tag.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0012.htmlHSEC-2023-0012 - git-annex checksum exposure to encrypted special remotes2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0012"
+cwe = [200]
+keywords = ["historical"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N"
+[[affected.versions]]
+introduced = "0.20110417"
+fixed = "6.20160419"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/checksum_exposure_to_encrypted_special_remotes/"
+[[references]]
+type = "FIX"
+url = "http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=b890f3a53d936b5e40aa9acc5876cb98f18b9657"
+</code></pre>
+<h1><em>git-annex</em> checksum exposure to encrypted special remotes</h1>
+<p>A bug exposed the checksum of annexed files to encrypted special
+remotes, which are not supposed to have access to the checksum of
+the un-encrypted file. This only occurred when resuming uploads to
+the encrypted special remote, so it is considered a low-severity
+security hole.</p>
+<p>For details, see commit <code>b890f3a53d936b5e40aa9acc5876cb98f18b9657</code>.</p>
+<p>No CVE was assigned for this issue.</p>
+<p>Fixed in <em>git-annex-6.20160419</em>.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0009.htmlHSEC-2023-0009 - git-annex command injection via malicious SSH hostname2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0009"
+cwe = [20, 78]
+keywords = ["ssh", "command-injection", "historical"]
+aliases = ["CVE-2017-12976"]
+related = ["CVE-2017-9800", "CVE-2017-12836", "CVE-2017-1000116", "CVE-2017-1000117"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
+[[affected.versions]]
+introduced = "0.1"
+fixed = "6.20170818"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2017-12976/"
+[[references]]
+type = "FIX"
+url = "http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=df11e54788b254efebb4898b474de11ae8d3b471"
+</code></pre>
+<h1><em>git-annex</em> command injection via malicious SSH hostname</h1>
+<p><em>git-annex</em> was vulnerable to the same class of security hole as
+git's <strong>CVE-2017-1000117</strong>. In several cases, <code>git-annex</code> parses a
+repository URL, and uses it to generate a <code>ssh</code> command, with the
+hostname to ssh to coming from the URL. If the hostname it parses is
+something like <code>-eProxyCommand=evil</code>, this could result in arbitrary
+local code execution.</p>
+<p>Some details of URL parsing may prevent the exploit working in some
+cases.</p>
+<p>Exploiting this would involve the attacker tricking the victim into
+adding a remote something like <code>ssh://-eProxyCommand=evil/blah</code>.</p>
+<p>One possible avenue for an attacker that avoids exposing the URL to
+the user is to use <code>initremote</code> with an SSH remote, so embedding the
+URL in the <em>git-annex</em> branch. Then the victim would enable it with
+<code>enableremote</code>.</p>
+<p>This was fixed in version <strong>6.20170818</strong>. Now there's a <code>SshHost</code>
+type that is not allowed to start with a dash, and every invocation
+of <code>git-annex</code> uses a function that takes a <code>SshHost</code>.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0010.htmlHSEC-2023-0010 - git-annex private data exfiltration to compromised remote2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0010"
+cwe = [200, 610]
+keywords = ["exfiltration", "historical"]
+aliases = ["CVE-2018-10857"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
+[[affected.versions]]
+introduced = "0.1"
+fixed = "6.20180626"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/"
+</code></pre>
+<h1><em>git-annex</em> private data exfiltration to compromised remote</h1>
+<p>Some uses of git-annex were vulnerable to a private data exposure
+and exfiltration attack. It could expose the content of files
+located outside the <em>git-annex</em> repository, or content from a
+private web server on localhost or the LAN. Joey Hess discovered
+this attack.</p>
+<p>To perform this attack, the attacker needs to have control over one
+of the remotes of the victim's <em>git-annex</em> repository. For example,
+they may provide a public <em>git-annex</em> repository that the victim
+clones. Or, equivalantly, the attacker could have read access to the
+victim's <em>git-annex</em> repository or a repository it pushes to, and
+some channel to get commits into it (e.g. pull requests).</p>
+<p>These exploits are most likely to succeed when the victim is running
+the <code>git-annex</code> assistant, or is periodically running <code>git annex sync --content</code>.</p>
+<p>To perform the attack the attacker runs <code>git-annex addurl --relaxed file:///etc/passwd</code> and commits this to the repository in some out
+of the way place. After the victim's git repository receives that
+change, <code>git-annex</code> follows the attacker-provided URL to the private
+data, which it stores in the <em>git-annex</em> repository. From there it
+transfers the content to the remote <em>git-annex</em> repository that the
+attacker has access to.</p>
+<p>As well as <code>file:///</code> URLs, the attacker can use URLs to private web
+servers. The URL can also be one that the attacker controls, that
+redirects to a URL that is accessible to the victim system (and not
+necessarily the compromised remote).</p>
+<h2>Fix</h2>
+<p>The issue was fixed by making <code>git-annex</code> refuse to follow
+<code>file:///</code> urls and URLs pointing to private/local IP addresses by
+default. Two new configuration settings,
+<code>annex.security.allowed-url-schemes</code> and
+<code>annex.security.allowed-ip-addresses</code>, can relax this security
+policy, and are intended for cases where the <em>git-annex</em> repository
+is kept private and so the attack does not apply.</p>
+<h2>Impact on external special remotes</h2>
+<p>One variant of this issue can exploit a vulnerable external special
+remote, and could not be prevented by <code>git-annex</code>. (<code>git-annex</code>'s
+own built-in special remotes are not vulnerable to this attack.)</p>
+<p>In this attack variant, the attacker guesses the hash of a file
+stored on the victim's private web server, and adds it to the
+<code>git-annex</code> repository. The attacker also has control of the server
+hosting an encrypted special remote used by the victim's <em>git-annex</em>
+repository. They cause that server to redirect to the victim's web
+server. This allows the attacker to verify if the victim's web
+server contains a file that the attacker already knows the content
+of, assuming they can guess the URL to it.</p>
+<p>Developers of external special remotes are encouraged to prevent
+this attack by not following such HTTP redirects.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0011.htmlHSEC-2023-0011 - git-annex GPG decryption attack via compromised remote2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0011"
+cwe = [200]
+keywords = ["exfiltration", "pgp", "historical"]
+aliases = ["CVE-2018-10859"]
+related = ["HSEC-2023-0010", "CVE-2018-10857"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
+[[affected.versions]]
+introduced = "0.20110417"
+fixed = "6.20180626"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/"
+</code></pre>
+<h1><em>git-annex</em> GPG decryption attack via compromised remote</h1>
+<p>A malicious server for a special remote could trick <code>git-annex</code> into
+decrypting a file that was encrypted to the user's GPG key. This
+attack could be used to expose encrypted data that was never stored
+in <em>git-annex</em>. Daniel Dent discovered this attack in collaboration
+with Joey Hess.</p>
+<p>To perform this attack the attacker needs control of a server
+hosting an <em>encrypted</em> special remote used by the victim's
+<em>git-annex</em> repository. The attacker uses <code>git annex addurl --relaxed</code> with an innocuous URL, and waits for the user's
+<code>git-annex</code> to download it, and upload an (encrypted) copy to the
+special remote they also control. At some later point, when the
+user downloads the content from the special remote, the attacker
+instead sends them the content of the GPG-encrypted file that they
+wish to have decrypted in its place (which may have been exfiltrated
+from the victim's system via the attack described in
+<strong>HSEC-2023-0010</strong> / <strong>CVE-2018-10857</strong>, or acquired by other
+means). Finally, the attacker drops their own copy of the original
+innocuous URL, and waits for the victim <code>git-annex</code> to send them the
+accidentially decrypted file.</p>
+<p>The issue was fixed by making <code>git-annex</code> refuse to download
+encrypted content from special remotes, unless it knows the hash of
+the expected content. When the attacker provides some other
+GPG-encrypted content, it will fail the hash check and be discarded.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0013.htmlHSEC-2023-0013 - git-annex plaintext storage of embedded credentials on encrypted remotes2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0013"
+cwe = [312]
+keywords = ["historical"]
+aliases = ["CVE-2014-6274"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
+[[affected.versions]]
+introduced = "0.20110401"
+fixed = "5.20140919"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2014-6274/"
+[[references]]
+type = "ARTICLE"
+url = "https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
+</code></pre>
+<h1><em>git-annex</em> plaintext storage of embedded credentials on encrypted remotes</h1>
+<p><em>git-annex</em> had a bug in the <strong>S3</strong> and <strong>Glacier</strong> remotes where if
+<code>embedcreds=yes</code> was set, and the remote used <code>encryption=pubkey</code> or
+<code>encryption=hybrid</code>, the embedded AWS credentials were stored in the
+Git repository in (effectively) plaintext, not encrypted as they
+were supposed to be.</p>
+<p>That means that anyone who gets a copy of the Git repository can
+extract the AWS credentials from it. Which would be bad.</p>
+<p>A remote with this problem cannot be enabled using <code>git annex enableremote</code>. Old versions of <em>git-annex</em> will fail with a GPG
+error; the current version will fail with a pointer to this web
+page.</p>
+<h2>Remediation</h2>
+<p>If your repository has this problem, chose from one of these
+approaches to deal with it:</p>
+<ol>
+<li>
+<p>Change your AWS credentials, so the ones stored in the clear in
+git won't be used.</p>
+<p>After changing the credentials, make sure you have a fixed
+version of git-annex, and you can then re-embed the new creds
+into the repository, encrypted this time, by setting the
+<code>AWS_SECRET_ACCESS_KEY</code> and <code>AWS_ACCESS_KEY_ID</code> environment
+variables, and running <code>git annex enableremote $remotename embedcreds=yes</code>.</p>
+</li>
+<li>
+<p>Fix the problem and then remove the history of the <em>git-annex</em>
+branch of the repository.</p>
+<p>Make sure you have a fixed version of <em>git-annex</em>, and force
+<em>git-annex</em> to rewrite the embedded creds, with encryption this
+time, by setting by setting the <code>AWS_SECRET_ACCESS_KEY</code> and
+<code>AWS_ACCESS_KEY_ID</code> environment variables, and running <code>git annex enableremote $remotename embedcreds=yes</code>.</p>
+<p>Then, to get rid of old versions of the <em>git-annex</em> branch that
+still contains the creds in cleartext, you can use <code>git annex forget</code>; note that it will remove other historical data too.</p>
+<p>Keep in mind that this will not necessarily delete data from
+clones you do not control.</p>
+</li>
+<li>
+<p>If you're sure that you're the only one who has access to the
+repository, you could decide to leave it as-is. It's no more
+insecure than if you had used <code>encryption=shared</code> in the first
+place when setting it up.</p>
+</li>
+</ol>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0002.htmlHSEC-2023-0002 - Improper Verification of Cryptographic Signature2023-06-19T21:35:33Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0002"
+cwe = [347]
+keywords = ["crypto", "historical"]
+aliases = ["CVE-2022-31053"]
+related = ["GHSA-75rw-34q6-72cr"]
+
+[[affected]]
+package = "biscuit-haskell"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.2.0.0"
+
+[[references]]
+type = "REPORT"
+url = "https://eprint.iacr.org/2020/1484"
+[[references]]
+type = "ADVISORY"
+url = "https://github.com/biscuit-auth/biscuit/security/advisories/GHSA-75rw-34q6-72cr"
+
+</code></pre>
+<h1>Improper Verification of Cryptographic Signature</h1>
+<p>The Biscuit specification version 1 contains a vulnerable algorithm that allows
+malicious actors to forge valid Γ-signatures. Such an attack would allow an
+attacker to create a token with any access level. The version 2 of the
+specification mandates a different algorithm than gamma signatures and as such
+is not affected by this vulnerability.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0007.htmlHSEC-2023-0007 - readFloat: memory exhaustion with large exponent2023-07-22T02:29:32Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0007"
+cwe = [1284, 789]
+keywords = ["toml", "parser", "dos"]
+
+[[affected]]
+package = "base"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+[[affected.versions]]
+# it was introduced earlier, but this is the earliest version on Hackage
+introduced = "3.0.3.1"
+
+[[affected]]
+package = "toml-reader"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.2.0.0"
+
+[[references]]
+type = "REPORT"
+url = "https://gitlab.haskell.org/ghc/ghc/-/issues/23538"
+[[references]]
+type = "REPORT"
+url = "https://github.com/brandonchinn178/toml-reader/issues/8"
+[[references]]
+type = "FIX"
+url = "https://github.com/brandonchinn178/toml-reader/pull/9"
+
+</code></pre>
+<h1><code>readFloat</code>: memory exhaustion with large exponent</h1>
+<p><code>Numeric.readFloat</code> takes time and memory linear in the size of the
+number <em>denoted</em> by the input string. In particular, processing a
+number expressed in scientific notation with a very large exponent
+could cause a denial of service. The slowdown is observable on a
+modern machine running GHC 9.4.4:</p>
+<pre><code>ghci> import qualified Numeric
+ghci> Numeric.readFloat "1e1000000" -- near instantaneous
+[(Infinity,"")]
+ghci> Numeric.readFloat "1e10000000" -- perceptible pause
+[(Infinity,"")]
+ghci> Numeric.readFloat "1e100000000" -- ~ 3 seconds
+[(Infinity,"")]
+ghci> Numeric.readFloat "1e1000000000" -- ~ 35 seconds
+[(Infinity,"")]
+</code></pre>
+<h2>In <em>base</em></h2>
+<p><code>Numeric.readFloat</code> is defined for all <code>RealFrac a => a</code>:</p>
+<pre><code class="language-haskell">readFloat :: RealFrac a => ReadS a
+</code></pre>
+<p>The <code>RealFrac</code> type class does not express any bounds on the size of
+values representable in the types for which instances exist, so
+bounds checking is not possible (in this <em>generic</em> function).
+<code>readFloat</code> uses to <code>Text.Read.Lex.numberToRational</code> which, among
+other things, calculates <code>10 ^ exponent</code>, which seems to take linear
+time and memory.</p>
+<p><strong>Mitigation:</strong> use <code>read</code>. The <code>Read</code> instances for <code>Float</code> and
+<code>Double</code> perform bounds checks on the exponent, via
+<code>Text.Read.Lex.numberToRangedRational</code>.</p>
+<h2>In <em>toml-reader</em></h2>
+<p>The issue was detected in <em>toml-reader</em> version 0.1.0.0, and
+mitigated in version 0.2.0.0 by immediately returning <code>Infinity</code>
+when the exponent is large enough that there's no reason to process
+it.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2024-0002.htmlHSEC-2024-0002 - out-of-bounds write when there are many bzip2 selectors2024-03-11T12:26:51Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2024-0002"
+cwe = [787]
+keywords = ["corruption", "vendored-code", "language-c"]
+aliases = ["CVE-2019-12900"]
+
+[[references]]
+type = "DISCUSSION"
+url = "https://gnu.wildebeest.org/blog/mjw/2019/08/02/bzip2-and-the-cve-that-wasnt/"
+
+[[references]]
+type = "DISCUSSION"
+url = "http://scary.beasts.org/security/CESA-2008-005.html"
+
+[[references]]
+type = "ADVISORY"
+url = "https://access.redhat.com/security/cve/cve-2019-12900"
+
+[[references]]
+type = "FIX"
+url = "https://sourceware.org/git/?p=bzip2.git;a=commit;h=7ed62bfb46e87a9e878712603469440e6882b184"
+
+[[affected]]
+package = "bzlib"
+cvss = "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.4"
+fixed = "0.5.2.0"
+
+[[affected]]
+package = "bz2"
+cvss = "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "1.0.1.1"
+
+[[affected]]
+package = "bzlib-conduit"
+cvss = "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.3.0.3"
+</code></pre>
+<h1>out-of-bounds write when there are many bzip2 selectors</h1>
+<p>A malicious bzip2 payload may produce a memory corruption
+resulting in a denial of service and/or remote code execution.
+Network services or command line utilities decompressing
+untrusted bzip2 payloads are affected.</p>
+<p>Note that the exploitation of this bug relies on an undefined
+behavior that appears to be handled safely by current compilers.</p>
+<p>The Haskell libraires are vulnerable when they are built using
+the bundled C library source code, which is the default
+in most cases.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2023-0001.htmlHSEC-2023-0001 - Hash flooding vulnerability in aeson2023-06-13T09:03:52Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2023-0001"
+cwe = [328, 400]
+keywords = ["json", "dos", "historical"]
+aliases = ["CVE-2022-3433"]
+
+[[affected]]
+package = "aeson"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+
+[[affected.versions]]
+introduced = "0.4.0.0"
+fixed = "2.0.1.0"
+
+[[references]]
+type = "ARTICLE"
+url = "https://cs-syd.eu/posts/2021-09-11-json-vulnerability"
+[[references]]
+type = "ARTICLE"
+url = "https://frasertweedale.github.io/blog-fp/posts/2021-10-12-aeson-hash-flooding-protection.html"
+[[references]]
+type = "DISCUSSION"
+url = "https://github.com/haskell/aeson/issues/864"
+</code></pre>
+<h1>Hash flooding vulnerability in aeson</h1>
+<p><em>aeson</em> was vulnerable to hash flooding (a.k.a. hash DoS). The
+issue is a consequence of the HashMap implementation from
+<em>unordered-containers</em>. It results in a denial of service through
+CPU consumption. This technique has been used in real-world attacks
+against a variety of languages, libraries and frameworks over the
+years.</p>
+https://haskell.github.io/security-advisories/advisory/HSEC-2024-0003.htmlHSEC-2024-0003 - process: command injection via argument list on Windows2024-04-09T22:14:47Z<pre><code class="language-toml">[advisory]
+id = "HSEC-2024-0003"
+cwe = [150]
+keywords = ["windows"]
+aliases = ["CVE-2024-3566", "VU#123335"]
+related = ["CVE-2024-1874", "CVE-2024-24576", "CVE-2024-22423"]
+
+[[references]]
+type = "ARTICLE"
+url = "https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/"
+
+[[references]]
+type = "ADVISORY"
+url = "https://kb.cert.org/vuls/id/123335"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell/process/commit/3c419f9eeedac024c9dccce544e5a6fb587179a5"
+
+
+[[affected]]
+package = "process"
+os = ["mingw32"]
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
+
+[[affected.versions]]
+introduced = "1.0.0.0"
+fixed = "1.6.19.0"
+</code></pre>
+<h1>process: command injection via argument list on Windows</h1>
+<p>The <em>process</em> library on Windows is vulnerable to a command injection
+vulnerability, via <code>cmd.exe</code>'s interpretation of arguments. Programs that
+invoke batch files (<code>.bat</code>, <code>.cmd</code>) and pass arguments whose values are
+affected by program inputs may be affected.</p>
+<p>This issue was discovered in many programming languages' Windows process
+execution behaviour. It was tracked by CERT/CC as <strong>VU#123335</strong> and a
+coordinated disclosure was made on 2024-04-09 17:00 UTC.</p>
+<p>A fix was released in <em>process-1.6.19.0</em>.</p>
+<h2>Background</h2>
+<p>Unlike POSIX systems, Windows does not have a mechanism for passing multiple
+arguments.Command line parsing is up to individual programs.</p>
+<p>The <em>process</em> library defines the <code>RawCommand</code> constructor for specifying an
+executable and its arguments:</p>
+<pre><code class="language-haskell">data CmdSpec
+ = ShellCommand String
+ | RawCommand FilePath [String]
+</code></pre>
+<p>On Windows, the <code>RawCommand</code> executable name and arguments are serialised into
+a single <em>command line</em> string, with separate arguments quoted separately.
+<em>process</em> then invokes the Windows <a href="https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa"><code>CreateProcess</code></a>
+routine with this command line string is given as the <code>lpCommandLine</code>
+argument.</p>
+<h2>Issue</h2>
+<p>When executing <code>.bat</code> or <code>.cmd</code> files, <a href="https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa"><code>CreateProcess</code></a>
+implicitly spawns <code>cmd.exe</code>. The <code>System.Process</code> command line construction
+does not escape characters with special meaning to <code>cmd.exe</code>. As a
+consequence, a command injection vulnerability arises when the following
+conditions are satisfied:</p>
+<ul>
+<li>Program running on Windows
+</li>
+<li>Program executes a <code>.bat</code> or <code>.cmd</code> file
+</li>
+<li>The argument values include or are influenced by program input
+</li>
+</ul>
+<h2>Demonstration</h2>
+<p>The following batch file, <code>test.bat</code>, merely prints the executable name the
+first two arguments (as interpreted by <code>cmd.exe</code>):</p>
+<pre><code>@ECHO OFF
+ECHO 0: %0
+ECHO 1: %1
+ECHO 2: %2
+PAUSE
+</code></pre>
+<p>The following Haskell program executes <code>test.bat</code> with basic string arguments.
+The output is as expected:</p>
+<pre><code>λ> readProcess "test.bat" ["a","b"] [] >>= putStrLn
+0: "test.bat"
+1: "a"
+2: "b"
+</code></pre>
+<p>However, we can use a close quote and the <code>&</code> character to induce <code>cmd.exe</code> to
+execute a program named in the argument:</p>
+<pre><code>λ> readProcess "test.bat" ["\"&calc.exe"] [] >>= putStrLn
+0: "test.bat"
+1: "\"
+2:
+</code></pre>
+<p>In addition to producing the above output, <code>calc.exe</code> is executed.</p>
+<h2>Mitigation</h2>
+<p>The lack of a general mechanism on Windows for safely conveying command line
+arguments to programs increases the risk of this kind of security issue. The
+fact that <code>cmd.exe</code> command line parsing is complex and poorly documented
+exacerbates this issue, and also heightens the risk that the fix is
+incomplete, or causes other issues.</p>
+<p>If possible, avoid executing batch files where arguments include or are
+influenced by untrusted program inputs. If it must be done, reject arguments
+that include special characters including <code>&</code> and <code>"</code>.</p>
+<h2>Fix versions</h2>
+<p><em>process</em> was modified to perform additional escaping and quoting
+when executing <code>.bat</code> and <code>.cmd</code> files on Windows (ignoring
+character case). The behaviour is unchanged in all other cases.</p>
+<p>The fix was released in <em><strong>process-1.6.19.0</strong></em>. The following GHC
+releases were the first in their series to include a fixed version
+of the <em>process</em> library:</p>
+<ul>
+<li><strong>GHC 9.10.1-alpha3</strong> (released 2024-04-15)
+</li>
+<li>GHC 9.8.x (<strong>no release with fix yet</strong>)
+</li>
+<li><strong>GHC 9.6.5</strong> (released 2024-04-16)
+</li>
+</ul>
+<p>Such a change in semantics should normally result in a major version
+bump. Because we expect very few (if any) users will be impacted by
+the behavioural change, the GHC team made a pragmatic decision to
+avoid the disruption that a major version bump would cause.</p>
+<h2>Acknowledgements</h2>
+<p>Security researcher <strong>RyotaK</strong> discovered and responsibly disclosed
+this vulnerability, coordinating the response across the many
+affected langauges and ecosystems.</p>
+<p>Ben Gamari commited and released the fix, which was based on a
+proposal by Fraser Tweedale. Fraser also improved the
+<code>System.Process</code> module documentation to better explain the Windows
+semantics.</p>
+
\ No newline at end of file
diff --git a/by-dates.html b/by-dates.html
new file mode 100644
index 00000000..913241d1
--- /dev/null
+++ b/by-dates.html
@@ -0,0 +1 @@
+Haskell Security advisories
\ No newline at end of file
diff --git a/by-packages.html b/by-packages.html
new file mode 100644
index 00000000..db9cf758
--- /dev/null
+++ b/by-packages.html
@@ -0,0 +1 @@
+Haskell Security advisories
\ No newline at end of file
diff --git a/index.html b/index.html
new file mode 100644
index 00000000..913241d1
--- /dev/null
+++ b/index.html
@@ -0,0 +1 @@
+Haskell Security advisories