| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| | |
Move garbage-input.dat to test case using it
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All-null transactions (i.e. a transaction where all postings have a null
amount) are discarded during parsing and the `xact` object is free'd.
But if the transaction contains a deferred posting this results in a
use-after-free vulnerability because a reference to the deferred posting
is stored in the account object which is later read when deferred
postings are applied after parsing is finished.
Ignore null deferred postings to prevent this – they should not have any
effect any way.
Thanks to Cory Duplantis for reporting this issue and providing an
initial analysis.
Ref TALOS-2017-0304, CVE-2017-2808
Fixes #1723
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cory Duplantis reported that "A specially crafted journal file can
cause [an] integer underflow resulting in code execution". Cory
provided this test case:
Expenses:Food:Groceries $ 37.50 ; ] [=2004/01/01]
Note the ] that comes before [ after the ;.
This issue was reported and described in great detail by Cory Duplantis
of Cisco Talos. This issue is known as TALOS-2017-0303 and has been
assigned CVE-2017-2807. Cory's description can be found at
https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0303
Fixes #1722
|
|
|
|
|
| |
Add a test case for issue #1703 which John Wiegley fixed in commit
56025cde ("Don't attempt to invert a value if it's already zero").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #1626.
The tokenizer eagerly classifies 4-digit integers as TOK_A_YEAR
tokens. In some contexts such as "every 1000 years", this causes
errors.
I think the tokenizer does not have enough information available to
distinguish between integers and years.
After this patch, the tokenizer will always classify integers as
TOK_INT tokens. The "has 4 digits" heuristic to determine if an
integer is a year is moved to the place where it's actually
needed (and it can be slightly more generic there, too).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes issue #1127. In my understanding, PR #552 was meant to fix
this, but was incomplete.
Without this patch, automated transactions are invisible to
assertions.
This patch fixes this by adding a flag to the account to tell it that
there is a new posting, analogous to the behavior of finalize().
I dug up issue #1127 too late to find that this is the same solution
proposed by @tbm. Although I wrote this independently, credit goes to
Martin Michlmayr (@tbm).
|
| |
|
|
|
|
| |
Fixes #520
|
|
|
|
|
|
|
|
|
|
|
| |
`changed_value_posts::create_accounts()` reuses the `<Revalued>` account
from `display_filter`, but when clearing `changed_value_posts`
`create_accounts()` would be called before the account had been
recreated by `display_filter_posts`. This results in a segfault when
using the --group-by option.
I'm not sure if `display_filter_posts` has the same problem but I
reordered the calls there too for good measure.
|
|\
| |
| | |
Fix bug where .total used in value exprs breaks totals
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Re-initialize (to VOID) totals for the account and its ancestors on adding
postings. Otherwise the cache intended for use by recursive calls of C++
function total() in computing family (i.e. account hierarchy) totals is
incorrectly retained from one top-level call to the next, causing
inconsistent and broken behaviour.
* Re-initialize (to false) calculated and gathered. Otherwise we won't
e.g. recalculate stale totals for ancestor accounts (e.g. won't recalculate
Assets:Savings total if Assets:Savings changes via a posting).
Although the value expression total function is used by ledger itself in
computing totals, this bug would only appear on use of .total in user-supplied
value expressions computed *during parsing* of ledger files, rather than after
parsing (I believe ledger only ever calls it for internal purposes after
parsing is complete).
It is possible this bug also affected other functions than total (perhaps even
in circumstances other than analagous to that described in the preceding
paragraph). I have not checked that.
|
|\ \
| |/
|/| |
Fix Bug 1182: Error message for parse failure after '='
|
| | |
|
|\ \
| | |
| | | |
Add regress test for bugs 550 and 584
|
| |/ |
|
|\ \
| | |
| | | |
Add regress test for bug 1055
|
| |/ |
|
|/ |
|
| |
|
|
|
|
| |
This was reported as Bug #1109
|
| |
|
|
|
|
| |
%g is not available in Windows strftime. See documentation at https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx
|
|
|
|
|
|
| |
With this change, 97% of the tests pass. See the build on appveyor for more info: https://ci.appveyor.com/project/Evan/ledger/build/build-49
I'll follow up with another PR to fix some of the remaining broken tests
|
| |
|
|\
| |
| | |
Use interval start date (period from/since) to initialize first period.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
transaction date
Bug 1159
Use interval start date (period from/since) to initialize first period.
This allows the offset of a period start to be specified
-p 'every 12 months from 2000-04-01'
will have periods
yyyy-04-01 to yyyy-03-31
....
If no from/since is specified for the period the first transaction date reported is used to initialize the period as before.
added test case regress/1159.test
|
|/
|
|
|
|
|
|
| |
weeks - calculate start date for finding period using remainer 400/periodlength to reduce number of iterations (perhaps this ought to follow the same conventio as years months and quarters)
add sample period command tests
add add day period tests for forecasts and budgets
add week period tests for forecasts and budgets - these do not change
|
|
|
|
|
| |
I'm sure I used $FILE for the final version but I must have committed
an old version.
|
|
|
|
| |
Fixes bug #981
|
|
|
|
|
| |
When converting a ledger.Value to unicode the Python API added
double quotes around it.
|
| |
|
|
|
|
| |
so that the tests run with a consistent environment.
|
|\
| |
| | |
Add regression test file for bug #1057
|
| |
| |
| |
| |
| | |
-(("/home/travis/build/ledger/ledger/test/regress/1057.test" 1 (21308 34912 0) nil "www.amazon.fr"
+(("/home/travis/build/ledger/ledger/test/regress/1057.test" 1 (21308 42112 0) nil "www.amazon.fr"
|
| | |
|
| | |
|
|/
|
|
| |
This reverts commit 8d1067c89c1c283accfeebb1ff35276b8eb35749.
|
|
|
|
|
| |
test/baseline/opt-permissive.test. Actually 634AA589 is the initial
commit that created permissive option.
|
|
|
|
|
|
| |
std::isspace(*e) returns false for the end of c-string null-byte.
Bugzilla: 1106
|
|
|
|
|
|
| |
Bugfix for #1102
Signed-off-by: Alexis Hildebrandt <afh@surryhill.net>
|
|
|
|
|
| |
when year was specified with literal Y or year directive, but not
when using apply year.
|
|
|
|
|
|
|
| |
ledger -f /dev/null reg -M test causes a segmentation fault,
see bug 730 and duplicates 1080 and 1084 for details.
Kudos to Ikke for helping with debugging.
|
| |
|
|
|
|
|
|
|
|
| |
Dates specified via --begin and --end are converted to a value expression
using an ISO 8601 (yyyy-mm-dd) date, but this date was not recognized by
ledger.
Bug fix for #1072
|
|
|
|
| |
Bug fix for #1074, a regression introduced by the fix for bug #375
|
|
|
|
| |
see pull request #320 / commit 4c8604266580b2
|
| |
|
| |
|