clawoflight / aursec Goto Github PK

A good readme is necessary before we go public.

It would be very nice to pass those checks.
If a warning really doesn't apply, it's category can be ignored.

Specifically, it would be nice to extract the state machine into it's own script to get an even more modular, reusable program.

We may run into problems at some point if multiple instances of aursec-chain mine blocks N are running at the same time.

We should check that and find a suitable global locking mechanism if necessary.

Expected behaviour: The manual interaction prompt should appear.
Actual behaviour: The hashes are shown, but the prompt doesn't appear.

Bug cases:

• above threshold, no match
• below threshold, no match

Correct cases:

• below threshold, match
• no hash in chain
• above threshold, match

It will also need to include an analysis of the security of Ethereum itself.

• check _aursec
• check _aursec-hash
• write _aursec-chain

This could be checked with acpi -a, for example, or possibly(?) systemd.
Some ideas:

• Reduce the priority of the running geth process
• Do not auto-mine if on battery

That requires this repo to be public, which I will do when the prototype works. That is currently blocked by #1 and #2.

The threshold is currently hard-coded. It should be read from a config file or environment variable instead.

The most important is to convert the form "do something." into "doing something..."

api cant connect to blockchain

Because of the complexity of the involved processes, it would be very helpful to handle some errors explicitly and give descriptive error messages:

• check exit statuses of critical commands
• parse the json response where applicable

I hate programs without proper documentation 😉

• aursec(1)
• aursec(7)
• aursec-chain(1)
• aursec-hash(1)

We need to find out what analyses we need to do and how long they should be.

Most likely through a systemd timer.

For example, "backtraces" like some of the examples in https://stackoverflow.com/questions/64786/error-handling-in-bash would be very helpful.
Additionally, messages for critical sections could be activated like in http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html if --debug was specified?

Most likely through some kind of hook.
This is currently blocked by aurutils/aurutils#184.

Because of the way we currently handle the consensus, we don't have any metric for how often it was committed vs the next most common hash.

This could e.g. be remedied by:

• using the difference between the most common hash and the second most common hash
• using a factor of the most common hash and the second most common hash
• ?

We could add this as an additional metric, or replace our current return value with it.

The worst case is we only mention this as a possible improvement in the evaluation section of the paper, but we'd be much more secure if we added that.
What do you think?

We need to minimize the danger of sourcing the PKGBUILD.
That means that we need to triple-check the firejail rules and actively try to break out until we are satisfied.

I'm just curious, how long does the aursec-init process take? It's been over six hours already, on a HP core i5 laptop.

Not sure how it works, but did you transpose some digits somewhere other than the comments in the aursec-parse-srcinfo script? Does shellcheck read the commented line in the script?

ie:
In bin/aursec-parse-srcinfo line 26:
if [[ "$val" =~ .*::(.git(@|+http).|.svn(+http|://).|.bzr+http.|.hg+http.) ]]; then
^-- SC1009: The mentioned parser error was in this regex grouping.
^-- SC1073: Couldn't parse this regex grouping.
^-- SC1072: Unexpected . Fix any mentioned problems and try again.
-vs-

# shellcheck disable=SC1702,SC1703,SC1009

I tried rebuilding after today's update on the AUR and still can't.

cut: ungültiger abnehmender Bereich „cut --help“ liefert weitere Informationen.
when getting no hash
maybe ask if curl result is 000000...0000

We will need one to initiate the p2p communication between chains.