Closed tharvik closed 1 year ago
https://github.com/angr/claripy/issues/271 is the shift issue
f402ee7dfe7db28adb885f3ac1ce845a8f684c12 should fix the verif issue... at the cost of verifying the iptables NF, but well, omelette, eggs, ...
In general all of the bpf stuff isn't for general use, it was for an example in the paper
as discussed, removing bpf & experiments in a next PR
f402ee7 should fix the verif issue... at the cost of verifying the iptables NF, but well, omelette, eggs, ...
hoo nice, thanks for fix, it works (waaay faster) now :)
need to revert the "CI on push only" change so it triggers for this PR as well, I guess? e436377f405772dfd14b02447de09b818e91949b
need to revert the "CI on push only" change so it triggers for this PR as well, I guess? e436377
ho right, forgot to drop the "TMP" commits, good catch
sadly, the more I run the verify-nf
, the more issues arises: dropping router because of the shift issue.
maybe if you open an issue or a PR for angr/claripy#271 they'll be more willing to take it since it affects >1 person 😇
(or maybe it's already fixed and the dependency versions need an update?)
(or maybe it's already fixed and the dependency versions need an update?)
yep, that's what I'm trying currently :crossed_fingers:
maybe if you open an issue or a PR for angr/claripy#271 they'll be more willing to take it since it affects >1
and if need be, fallback on that, maybe with a PR to push it even more!
(or maybe it's already fixed and the dependency versions need an update?)
yep, that's what I'm trying currently crossed_fingers
sadly, it isn't fixed w/ latest release :disappointed:
maybe if you open an issue or a PR for angr/claripy#271 they'll be more willing to take it since it affects >1
and if need be, fallback on that, maybe with a PR to push it even more!
PR opened at https://github.com/angr/claripy/pull/297 :) waiting for merge and release, then bumping theses deps and then most of the NF can be verified :tada:
alright, upstream released, deps bumped, one last review and we can merge it IMO :)
Does the tmp commit still need a revert? Or is there something else preventing CI from working on this PR?
Does the tmp commit still need a revert?
a rebase & force push got rid of it
Or is there something else preventing CI from working on this PR?
hum, as an external contributor is adding the CI, maybe you need to enable the checks somehow? or you can see the action ran on the c4dt fork
Weird, GitHub's docs say I should see something about this, oh well.
add GitHub actions support to automatically check that PRs lint/compile/build/...
lpm_*
impl), everyNET=dpdk
need some unknown headermake verify-*
andmake
will take care of its creationtool-test
target, w/ venv auto-gennf/*/config
were unvalid (missing,
)questions
nop
), the CI bails out after 6h, locally it is been running for a while now. did I missed smth (like using my own riced z3)? some magic compiling option that simplifies angr's job?