This test appeared to have failed after adding source positions to
generated transactions. This is because the generated transaction id for
web pages appears to be dependent on whether the transaction has an
associated source file. Because it has one associated now, the id was
updated to be 'transaction-2-1' for instance, instead of
'transaction-0-1' as it would have been before. The fix is to change the
test.
This increases composability and avoids some ugly case handling. We
re-export runExceptT in Hledger.Read.
The final return types of the following functions has been changed from
IO (Either String a) to ExceptT String IO a. If this causes a problem,
you can get the old behaviour by calling runExceptT on the output:
readJournal, readJournalFiles, readJournalFile
Or, you can use the easy functions readJournal', readJournalFiles', and
readJournalFile', which assume default options and return in the IO
monad.
We no longer rely on git tags and git describe output, since it's
hard to reliably select the correct tag eg for minor releases.
We might use them again in future for dev builds, but it requires
adding git describe --match support to githash. For now,
* Program name, OS and architecture are always shown.
* The package version is always shown.
* If there is git info at build time, the latest commit hash and commit date are shown.
Example outputs:
A homebrew binary, not built in git repo: hledger-ui 1.24, mac-aarch64
A CI release build, built in git repo: hledger 1.24.1-g455b35293-20211210, mac-x86_64
API changes:
* new type synonyms ProgramName, PackageVersion, VersionString
* versionStringForProgname -> versionString with extra argument
* versionStringFor -> versionStringWith with extra argument
(SourcePos, SourcePos).
This has been marked for possible removal for a while. We are keeping
strictly more information. Possible edge cases arise with Timeclock and
CsvReader, but I think these are covered.
The particular motivation for getting rid of this is that
GenericSourcePos is creating some awkward import considerations for
little gain. Removing this enables some flattening of the module
dependency tree.
to Hledger.Cli.
Since the git hash changes whenever any file in the repository changes,
this means Hledger.Cli.Version needs to be recompiled all the time.
Since it is at the bottom of the module hierarchy, this means that the
whole hledger package needs to be recompiled. We instead move the
TemplateHaskell splice to one of the top modules, so much less needs to
be recompiled.
Note: Ghc seems to be able to get out of most of the recompiling a lot
of the time (due to caching?), but this makes things more reliable.
This fixes a reported Stored XSS vulnerability in toBloodhoundJson by
encoding the user-controlled values in this payload into base64 and
parsing them with atob.
In my exploration of the vulnerability with various payloads I and
others crafted, it would appear that this is the only available XSS in
hledger-web in relation to stored accounts and transaction details. If
there is other parts of the UI which may contain user-controlled data,
they should be examined for similar things. In this instance,
protections provided by yesod and other libraries worked fine, but in a
bit of code that hledger-web was generating, the user could insert a
</Script> tag (which is valid HTML and equivalent to </script> but not
caught by the T.Replace that existed in toBloodhoundJson) in order to
switch out of a script context, allowing the parser to be reset, and for
arbitrary JavaScript to run.
The real fix is a bit more involved, but produces much better results:
Content-Security-Policy headers should be introduced, and using
sha256-<hash of script> or a different algorithm, they should be marked
as trusted in the header. This way, if the (in-browser) parser and
hledger-web generator disagree on the source code of the script, the
script won't run. Note that this would still be susceptible to attacks
that involve changing the script by escaping from the string inside it
or something similar to that, which can be avoided additionally by using
either the method used in this commit, or a proper JSON encoder.
The second approach has the advantage of preventing further XSS, to the
extent specified above, in practice, a combination of both should be
used, b64 for embedded data and the CSP sha256-hash script-src over
everything else, which will eliminate all injected or malformed script
blocks (via CSP), in combination with eliminating any HTML closing tags
which might occur in stored data (via b64).
This vulnerability appears to have been first introduced when
autocompletion was added in hledger-web, git tag hledger-0.24, commit
hash: ec51d28839
Test payload: </Script><svg onload=alert(1)//>
Closes#1525
rather than as a postprocessing step. (#1638)
This allows us to have a uniform procedure for balancing transactions,
whether they are normal transactions or forecast transactions, including
dealing with balance assignments, balance assertions, and auto postings.
style amounts according to that argument. journalAddForecast and
journalTransform now return an Either String Journal.
This improves efficiency, as we no longer have to restyle all amounts in
the journal after generating auto postings or periodic transactions.
Changing the return type of journalAddForecast and journalTransform
reduces partiality.
To get the previous behaviour for modifyTransaction, use modifyTransaction mempty.
This is done to be more consistent with future field naming conventions,
and to make automatic generation of lenses simpler. See discussion in
\#1545.
rsOpts -> _rsReportOpts
rsToday -> _rsDay
rsQuery -> _rsQuery
rsQueryOpts -> _rsQueryOpts
reportq from the ReportSpec, rather than being supplied as a separate
option.
This is the same approach used by the other reports, e.g. EntryReport,
PostingReport, MultiBalanceReport. This reduces code duplication, as
previously the reportq had to be separately tweaked in each of 5
different places.
If you call accountTransactionreport, there is no need to separately
derive the report query.
functions to AccountTransactionsReport.
If you use transactionsReport, you should either use entryReport if you
don't require a running total, or using accountTransactionsReport with
thisacctq as Any or None (depending on what you want included in the
running total).
This produces identical results. The only fields used in the TransactionReport were torig, split, and amt.
- torig is the same as in entriesReport
- since transactionsReport calls accountTransactionsReportItems with
None as thisacctq, all accounts are considered ‘other accounts’, so
amt is always zero, and ($if not split && not (mixedAmountLooksZero amt)) never fires.
- So the only thing used is torig, and we can just get that from the
entriesReport.
