BaSzErr - blog:2016:02:29

auto-generating_revision_and_tags

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:24 +0000

2016-02-29 - auto-generating revision and tags

most project deal with providing build-reversion and tags to build manually. there is however an interesting trick to automate getting revision number in cmake. while not perfect (one must rebuild twice when ninja is used)), it is reasonably useful to put into a real project.

i've introduced the concept for getting revision ID (git's commit hash) and list (!!) of tags in production system, we're currently working on. it works like a charm. from now on, whenever we get logs from testers, we can clearly see which version of our software was used, even if there are human-errors in description fields. it turned out to be quite a time savior, in some cases.

bugtracking_at_scale

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:24 +0000

2016-02-29 - bugtracking at scale

since some time i work in a project that is part of a much larger system. in reality it means it is not uncommon to have a problem report from testers, that takes days-to-weeks to fix, and spans multiple system components, and different locations. often it means you're added into a middle of some ongoing discussion, that goes on and for 10s of pages. it's hard to get up to speed quickly here, and filter “findings” that turned out to be inaccurate from the ones that are currently main subjects.

i recently came to a conclusion bugtracker could be amended to support two tabs: discussion (forum-like) and facts (wiki). on forum ppl cloud just put in what they think, ask questions, loop other is, etc… business as usual. whenever something relevant has been found – like an important part of log, or interesting fact about particular test setup – it would be then put on “facts” tab, so that when a new person is added to a discussion, she can skip all the discussion and just go through “facts” to see what's up and what to do next.

an interesting side effect would be a nice option for analyzing historical bugs. if you need to know what was the bug's reason, how it was located and what caused it, you just open one, short page with all the important pieces of information and you're good. no need to look for old @s (which you may not have even participated in, in a first place!) and reading through 30 pages of free-form text, to find 3 relevant sentences.

now having such a “facts” page organized in a computer-readable fashion would help to do data mining. this way system could, in theory, try to correlate typical scenarios with historical issues. for instance having similar parts of logs marked as relevant in two problem reports, could directly point out similar issue and direct ppl towards a solution (if the problem is known) or right subsystem (if the problem is new, but similar to the one already processed). it would probably do a good job at detecting duplicates as well.

c_interactive_console

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:24 +0000

2016-02-29 - C++ interactive console

ppl often complain about lack of C++ interactive console to try things out fast, like in say python. actually there is at least one project that does that – cling. it is not perfect, but it is already usable at this stage.

green_light_for_mass-invigilation_in_poland

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:24 +0000

2016-02-29 - green light for mass-invigilation in poland (and how to deal with it)

around the christmas/new year's eve time 2015 was an interesting time for PL citizens. new regulations, that allow widespread invigilation, have been accepted. it came live earlier this month. this is quite a problem for at least several reasons – just to quote few interesting opinions here:

Robert A. Heinlein: Secrecy is the keystone to all tyranny. Not force, but secrecy and censorship. When any government or church for that matter, undertakes to say to its subjects, “This you may not read, this you must not know,” the end result is tyranny and oppression, no matter how holy the motives. Mighty little force is needed to control a man who has been hoodwinked in this fashion; contrariwise, no amount of force can control a free man, whose mind is free. No, not the rack nor the atomic bomb, not anything. You can't conquer a free man; the most you can do is kill him.
Edward Snowden: Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.
Vladimir Lenin: Supervision is a base of trust. (any1 else see the irony?)

thus having said, i must admit i'm a bit shocked by how few ppl do really care about their privacy. “i have nothing to hide” is probably the most widespread argument. i usually reply with something like: “so why do you have curtains in your windows?” or “i do not recall seeing you running naked on the streets – are you ashamed of something?”.

my observation is that in general tech ppl are more aware and do “fight back”.

dealing with the problem

i'm using full-disk encryption for over a decade now. since sometime i'm also using Signal (software) for texting (unfortunately not that many ppl i know use it as well). recently i've setup VPN on my router, to access the internet. there is an interesting comparison of VPN providers you can filter to find your best match. what is worth checking making sure of?

company is located OUTSIDE of fourteen eyes countries. otherwise the cure might be worse than the disease, as “14 eyes” have much bigger budget for mass invigilation than poland.
it should not log traffic. preferably nothing should be logged.
should accept p2p. there are certain occasions p2p can be the only source of information, that is not centrally-controlled, thus cannot be easily shut-down.
4096 bit RSA key. this unfortunately is not provided in the mentioned spreadsheet, so you must check it out on your own. there is an interesting discussion on VPNs, where a reference is made to an article, pointing out that NSA can break 1024 bit RSA in a massive scale.

configuration

configuration of OpenVPN is nowadays simple, since most providers offer ready-to-go configuration files. just download it, put in your user/pass, and you're good to go. this should be set on your router, so that all networked devices do use your VPN. having OpenWRT or other linux distro, means this is a piece of cake – just setup OpenVPN client on that device and you're done!

there is however one more problem, that is not commonly mentioned, when talking about VPN. VPN does work over an actual network, that is by itself, fully operational as well. now if you loose your VPN connectivity in a background (say – due to a malfunction of router) you're connection becomes wide open, and most likely you will not even notice it!

it actually gets worse. if some1 wants to eavesdrop your traffic, and has an access to, say ISP's network, then she can block your VPN traffic, forcing its disconnection and kaboom! you're now being watched again!

in order to prevent it from happening, your router must be configured, so that it does NOT allow any “open traffic” to happen directly. you can play around with blocking DNS' access, but it will not make a trick for connections to IPs that are already cached. what you should do instead, is to block ALL forwarded traffic, that is not directed to your VPN access node directly. for OpenWRT this means adding custom rules like these:

iptables -A forwarding_rule -o your_wan_dev -d 1.1.1.1 -j ACCEPT # 1st VPN access node from a list
iptables -A forwarding_rule -o your_wan_dev -d 1.1.1.2 -j ACCEPT # 2nd VPN access node from a list
iptables -A forwarding_rule -o your_wan_dev -j REJECT # nothing else is allowed

this way, if VPN goes down, internet traffic is blocked as well. if you are using multiple gateways, OpenVPN will automatically switch between them, if connection is lost.

technical downsides

aside from an obvious point, that VPN, even if cheap, it's still not free, there is more. using VPN means at least 2x longer RTT (one extra point along the way). in real live however usually 4-6x longer RTTs are to be assumed (4-5x is a good result you should aim for). assuming you have reasonable “raw” network connection, this won't be a practical problem even for gaming. the real challenge is encryption – or the CPU power of your network access point. if you have over 8Mbps connection, pretty much none of the off-the-shelf home routers will deal with OpenVPN using 4096 bit encryption, effectively limiting out bandwidth.

there are many mini-ITX motherboards available, that have x86/amd64 CPUs on board, without any moving parts. this should do for encryption. putting such a mini-PC with two ethernet cards in a closet can be a nice way of dealing with CPU-power loss. while it is more expensive than even a very good router, as a free bonus it can serve as a high-speed NAS (cheap ones don't usually go beyond ~20MB/s and more expensive ones are usually just not worth it).

opencl_and_c

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:24 +0000

2016-02-29 - OpenCL and C++

OpenCL is a very nice initiative. i however only used to support C, when preparing its kernels. the good news is that, since since OpenCL 2.1 C++14 support has been provided. have fun! :)

remote_console

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:24 +0000

2016-02-29 - remote console

recently i was asked to assist with on linux system remotely. there were just few commands to execute, but it is usually time-consuming to explain something like:

rm -rf `du -s /tmp/* | sort -n | tail -3 | awk '{ print $2 }'`

over a phone, to a person who is not used to working with a shell on a daily basis.

first i've asked for for an ssh access. it was however not possible, since remote computer was behind NAT, on a local network. i had a public IP, i could forward to my SSH on local machine and ask to do a reverse tunnel so that i could connect back to a person's machine. it did not however felt nice, to give an access to my hardware (just a healthy paranoia). finally i proposed to use netcat for this. on my PC:

ncat --ssl -v -l 0.0.0.0 1234

i've tested remote end with help of TOR¹⁾:

torify ncat --ssl -v -e /bin/bash my.remote.address 1234

and confirmed i have a console to work with. then i've asked remote end to join, by typing this on his console:

ncat --ssl -v -e /bin/bash my.remote.address 1234

and voila! remote shell to play around. :) it was far from SSH, in terms of usability, but to execute few commands it was just fine.

later on it turned out we'd need to do X forwarding to continue, so the day ended using teamviewer from inside VM²⁾. i'm still thinking about a better solution for non-public IP scenario…

¹⁾

creative use for TOR, to check if all the port forwardings do work fine

²⁾

zero trust for closed-source apps! :P