Age | Commit message (Collapse) | Author |
|
svn path=/branches/tk705/; revision=6210
|
|
keys.
svn path=/branches/tk705/; revision=6209
|
|
cleanup of POW.c RPKI conformance checking code.
svn path=/branches/tk705/; revision=6208
|
|
from having SIA extensions, unlike all other RPKI certificates which
are required to have them.
Start moving RPKI conformance checks which can be performed in Python
out of POW.c, tag a bunch more for consideration.
svn path=/branches/tk705/; revision=6204
|
|
matters more when object has a __str__() method.
svn path=/branches/tk705/; revision=6199
|
|
summary from rcynic-text.
svn path=/branches/tk705/; revision=6187
|
|
svn path=/branches/tk705/; revision=6186
|
|
Get full rsync code working, history cache and all.
svn path=/branches/tk705/; revision=6184
|
|
OpenSSL certificate verification errors.
svn path=/branches/tk705/; revision=6181
|
|
makes the C code considerably simpler.
svn path=/branches/tk705/; revision=6180
|
|
X509Store.verify() to X509.verify(). Result seems to run properly
with trivial modification to existing Python BPKI code.
RPKI extended validation via this interface (the real point of this
exercise) still not tested.
svn path=/branches/tk705/; revision=6176
|
|
POW.c, still totally untested. X.509 certificate validation is in a
transitional state, currently spiced with awful kludges so that we're
still doing the right thing cryptographically, albeit in a completely
disgusting way as far as the API is concerned. Serious cleanup
needed, but wanted to get a post-merge version with CMS and X.509
working again after the merge into the repository for backup.
svn path=/branches/tk705/; revision=6175
|
|
svn path=/branches/tk705/; revision=6173
|
|
Regenerate EE certificates along with everything else when activating
a new CADetail (ie, when rolling a CA key).
svn path=/branches/tk705/; revision=6172
|
|
hacks: in practice, we always bypassed it (except when we forgot...).
Make sure we revoke and withdraw the old certs and objects for ROAs
and Ghostbusters rather than the new ones during forced reissue.
svn path=/branches/tk705/; revision=6171
|
|
.publish_world_now() to something a little less whacky. Consolidate
fix for singleton URIs in SIA fields.
svn path=/branches/tk705/; revision=6170
|
|
Tweak publication callback mechanism to use uri instead of tag.
svn path=/branches/tk705/; revision=6169
|
|
svn path=/branches/tk705/; revision=6168
|
|
svn path=/branches/tk705/; revision=6167
|
|
svn path=/branches/tk705/; revision=6166
|
|
rpkid_task code. Combine and simplify CRL and manifest generation.
svn path=/branches/tk705/; revision=6164
|
|
svn path=/branches/tk705/; revision=6163
|
|
understands Django's exotic metaclasses, which in turn allows us to
re-enable a number of pylint checks we had disabled. While we were at
this, stripped out a bunch of old pylint pragmas, then added back the
subset that were really needed. As usual with pylint, this turned up
a few real bugs along with an awful lot of noise.
svn path=/branches/tk705/; revision=6162
|
|
sequence trace code to rpki.rpkidb.models to assist in simplifying
some of the gratuitously complicated method call chains. Various
trivial PyLint cleanups.
svn path=/branches/tk705/; revision=6161
|
|
RPKI validation in POW.c. So far this is mostly notes and the support
for the status code mechanism.
svn path=/branches/tk705/; revision=6158
|
|
svn path=/branches/tk705/; revision=6157
|
|
svn path=/branches/tk705/; revision=6156
|
|
for portability. With this change, the GUI appears to work with SQLite3.
svn path=/branches/tk705/; revision=6155
|
|
running with new code base. Now working with
$ yamltest.py --sql mysql --gui smoketest.1.yaml
svn path=/branches/tk705/; revision=6153
|
|
or commenting conventions should be shot. If it so happens that it is
inconvenient to shoot him, then he is to be politely requested to recode
his program in adherence to the above standard."
-- Michael Spier, Digital Equipment Corporation
svn path=/branches/tk705/; revision=6152
|
|
postgresql sort of works with the core daemons and rpkic, well enough
to generate RPKI objects if one hand configures it, but one can't even
run migrations for the GUI, due to a few non-portable SQL data types,
and migrations from earlier version of the IRDB have similar problems.
svn path=/branches/tk705/; revision=6151
|
|
operations, so simplify code and schema by removing gratuitous
transformations to and from binary format.
svn path=/branches/tk705/; revision=6150
|
|
backend. Switch yamltest's default database configuration to sqlite3.
MySQL still has character set issues, which are almost certainly to do
with the communication channel rather than the database tables. It's
possible that one of the newer DB API drivers for MySQL fixes this,
might be worth trying one of them at some point (see the "MySQL notes"
discussion of MySQL DB API drivers in the Django documentation).
svn path=/branches/tk705/; revision=6149
|
|
database, so the garbage collector can clean it up automatically.
svn path=/branches/tk705/; revision=6148
|
|
else.
svn path=/branches/tk705/; revision=6147
|
|
incorrectly coded UTF-8 in BLOB fields holding ASN.1 DER data. This
is wrong in so many ways that I don't even know where to start, but,
bottom line, forcing Latin1 here is just making MySQL 5.6+ revert to
the behavior in MySQL 5.5.
This is just a workaround. The real solution is probably to switch to
an SQL engine that's not quite such a kludge tower.
svn path=/branches/tk705/; revision=6146
|
|
helped the MySQL UTF-8 whining. Same Python code running with MySQL
5.5 doesn't do this, so it's some kind of upgrade trainwreck.
BinaryField uses BLOBs too, just as one would expect, so in theory
this can't be happening. So it's an undocumented feature. Yum.
But we wanted to move to BinaryField anyway, and doing so doesn't seem
to have made the problem worse, so committing the changes.
svn path=/branches/tk705/; revision=6145
|
|
up-down protocol specification and, more importantly, avoid spurious
CMS Replay errors.
svn path=/branches/tk705/; revision=6144
|
|
UTF-8 whining on what are supposed to be binary fields that's probably
the result of a MySQL upgrade, and CMS Replay exceptions due to the
pseudo-random order in which HTTP client connections run in Tornado.
The UTF-8 mess is probably a good reason to change over to Django's
native binary field type, which we were going to want to do anyway.
The CMS Replay problem is not Tornado's fault: we probably would have
seen it in the old code were it not for an accidental side effect of a
long-since-abandoned attempt to use persistent HTTP connections. The
fix is probably to serialize requests to a particular host using use a
tornaodo.queue.Queue() object, or something like that.
svn path=/branches/tk705/; revision=6143
|
|
were ordinary functions. May want some kind of naming scheme or other
convention to make it easier to avoid this sort of thing.
svn path=/branches/tk705/; revision=6142
|
|
svn path=/branches/tk705/; revision=6140
|
|
quite working perfectly yet (cron is a bit wonky) but manages to
produce an initial set of ROAs without thowing any exceptions, and
code is already much cleaner than the old callback-based horror.
svn path=/branches/tk705/; revision=6139
|
|
svn path=/branches/tk705/; revision=6138
|
|
svn path=/branches/tk705/; revision=6137
|
|
svn path=/branches/tk705/; revision=6135
|
|
bad choice for something implemented in Python, holdover from an older
specification, but Django ORM's troubles with "self" as a keyword
argument were the last straw. Enough already. Backwards
compatability should be a straightforward data migration.
svn path=/branches/tk705/; revision=6134
|
|
svn path=/branches/tk705/; revision=6129
|
|
Django ORM. Duct tape and bailing wire everywhere, much clean-up left
to do, but basic "make yamltest" suite runs. Much of the clean-up
isn't worth doing until after revamping the I/O system, as it'll all
change again at that point anyway.
svn path=/branches/tk705/; revision=6127
|
|
svn path=/branches/tk705/; revision=6126
|
|
svn path=/branches/tk705/; revision=6123
|