visualize the GnuPG web of trust - visualization

Is there some way to visualise the GnuPG web of trust? With my (or any other) key in the middle, with the signed keys in the first circle, the trustpersons' trustpersons in the next and so on?
If there is nothing like that, I should be able to build something like that based on the key signatures from my lokal keyring, right?

One approach is to convert the output of gpg --list-sigs to a dot file that can be rendered into a graph with the graphviz tools.
Use gpg, sig2dot, and dot like this:
gpg --list-sigs | sig2dot.pl > gpg.dot
dot -Tps gpg.dot > gpg.ps
evince gpg.ps

Related

VSCode - How to delete a specific command history in command palette (as opposed to clearing everything)?

I would like to delete several commands from VSCode command palette's "recently used" section, but not clear the entire history. How?
So in Chrome's Omnibar, you can use Shift+del to delete a suggestion. But I cannot find an analogous shortcut in VSCode's command palette.
I also looked for a "meta-command" for this, but I only found Clear Command History in the command palette. I want something like Edit/Manage Command History instead.
Edit: a history file that I can directly edit (analogous to ~/.bash_history for Bash) would also do.
Okay, so this question was upvoted today, which brought it back to my attention. I decided to bite the bullet this time and dug into the nuts and bolts of VSCode's files and found where this history is stored.
TLDR
Modifying the history is doable (obviously, because it has to be stored somewhere), but it's not very practical at all. Unfortunately it will continue to be very difficult, until VSCode implements official support (which may be never). I recommend using the following method ONLY IF you absolutely need a history entry deleted.
The method
Note:
I'm using Code OSS (the debranded build of VSCode) on Linux. The method should be applicable to other OSes, but the specific commands and paths will be different.
This method works on VSCode 1.74.2, the latest version as of 2023-01-04. It may or may not work with future versions.
0. Exit VSCode completely
Obviously.
Check with your resource/task/process manager to make sure VSCode is completely killed. If you're not sure, just reboot.
1. Locate lastSyncglobalState.json
This file contains the command palette history data. On Linux it's located at $XDG_CONFIG_HOME/Code - OSS/User/sync/globalState/lastSyncglobalState.json. On Windows it's probably under a similar path in %APPDATA%. Not sure about MacOS. Copy this file to somewhere convenient.
If you are curious how I discovered this file, I did a search of a command I recently ran using rg in $XDG_CONFIG_HOME/Code - OSS/. Note that you have to search the "programmatic name" of the command, not its display name (e.g. rust-analyzer.reload, not rust-analyzer: Restart server).
2. Extract the relevant data
If you open up lastSyncglobalState.json with a text editor directly, you'll find a Russian doll of escaped JSON. Technically you can do the modification straight from here, but I'm not eating this 💩.
Fortunately jq makes this somewhat easier:
# This is Bash but I think it works on Windows CMD too? Not sure.
jq '.syncData.content | fromjson.storage."commandPalette.mru.cache".value | fromjson.entries' lastSyncglobalState.json > history.json
The extracted history.json should look something like this:
[
{
"key": "rust-analyzer.debug",
"value": 297
},
{
"key": "rust-analyzer.syntaxTree",
"value": 298
},
// more entries...
]
3. Modify
Copy history.json to history-new.json, and simply remove the entries you want to delete from history-new.json. Do not modify history.json; we will need it in a bit.
Check that it's still valid JSON after your edits; in particular make sure that you have not left a trailing comma in the array.
4. Write back
The responsible way to do this is to perform the inverse of step 2, starting from the bottom up, update a field, json-encode, then update the field one level up, json-encode again, etc, until we get to the top level. But that's an enormous pain in the arse to do with jq.
Much easier I think, simply double (triple?) json-encode history-new.json, and perform a textual replacement. This is where the original history.json comes in handy:
# In lastSyncglobalState.json, replace the output of...
jq 'tojson | tojson' history.json
# with the output of...
jq 'tojson | tojson' history-new.json
Note that since the output of jq is quoted, it's necessary to remove the outmost layer of quotes (") on both the search string and the replace string. With rg we can automate this:
jq 'tojson | tojson' history.json | rg '^"(.+)"$' -r '$1'
jq 'tojson | tojson' history-new.json | rg '^"(.+)"$' -r '$1'
Of course there's nothing wrong with doing it manually, or with using sed instead if you want to. Again, just be careful you're not creating invalid JSON.
5. Copy back into VSCode directory
Honestly, you probably want to make a backup of the entire $XDG_CONFIG_HOME/Code - OSS/ directory (or whatever it is on your machine) before doing this. It's probably big I know, but I'm not sure what crazy thing VSCode will do if it finds lastSyncglobalState.json unparseable. Better be safe than sorry.
After you've done that, just copy your modified lastSyncglobalState.json back into $XDG_CONFIG_HOME/Code - OSS/User/sync/globalState/lastSyncglobalState.json and voila.
VSCode terminal uses external shell. For linux the default shell it's bash, for windows it's powershell.
If your terminal shell is powershell, go to C:\Users\john\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline on your file explorer
Visit this link for more details, if the above does not help.

How can I create a dot file that contains two schemas in the same database?(PostgreSQL)

Basically I have two schemas on the same DB that I would like to put into a dot file using postgresql_autodoc. I have tied creating two separate .dot files and then packing them with gvpack.
However I run into an error telling that the first node in one of the files does not have a position.
I've also tried just combining the two graphs without packing and then running the command I found on stackoverflow (ccomps -x graph.dot | dot | gvpack -array3 | neato -Tsvg -n2 -o graph.svg), but it seems that the connections are not there.
Perhaps there is another program I could use that will create a master dot that contains the two schemas?
My ultimate goal here is to make it completely automated using a php and shell script combo that I can run after making changes and pull subsystems out of it using gvpr.
Let me know what you think guys! (64bit Ubuntu 12.04.2 - in case that's also needed)
This may seem like a bit simple, because I haven't worked with the .dot files much but we use pg_autodoc to generate files with all schemas in a database. We haven't had any problems.
So the first thing to do is just to run pg_autodoc on your database and generate a .dot file without selecting schemas. This will give you all objects in all schemas.
If that fails to give you something you can use with your toolchain, then the next question is why, but that will have solved your immediate question.

how do I get a profile's "link" from Facebook's graph in a bash script?

I'm trying to write a script that needs to extract a list of public facebook page URLs and stores them in a flat text file. I've already downloaded a few http://graph.facebook.com/$NUMBER files with wget, but I'm having trouble separating out the URL because of the weird delimiting that they use. Here's the general format (I'll use a fictitious example):
{"id":"4","name":"John Smith","first_name":"John","last_name":"Smith","link":"http:\/\/www.facebook.com\/john.smith","username":"john.smith","gender":"male","locale":"en_US"
That's JSON, and so your best bet is to use a tool that actually understands JSON. If you have python installed, it comes stock with json support, and so it's easy to do something like:
$ echo '{"id":"4","name":"John Smith","first_name":"John","last_name":"Smith","link":"http:\/\/www.facebook.com\/john.smith","username":"john.smith","gender":"male","locale":"en_US"}' | python -c 'import json,sys; print json.load(sys.stdin)["link"]'
http://www.facebook.com/john.smith
Not a pure bash solution, but parsing JSON in bash seems like a lot of hard and unnecessary work, imo.

Programmatically change text config files in Linux with minimal effort

I am looking for a tool that would ease the modification of text configuration files for tasks like:
Set ForwardAgent yes on /etc/ssh/ssh_config
Append HGUSER to AcceptEnv in /etc/ssh/sshd_config (that's more complex as it does accept several params, if yours is not alread there it should add it)
Most important:
running it several times should have no side effects.
if something looks weird, it should complain (for example if you find the same line several times in a file, or if the expected syntax does not match).
Is there any linux tool that can easily be used to automate things like this?
The whole point is to be able to write these config patches somewhere so you can deploy them on several machines or on a new machine when needed.
I would certainly do this with bash scripting. Here is a great tutorial.
http://linuxconfig.org/Bash_scripting_Tutorial
to change a line in a file you could do something like:
check the file exists
grep for the value you want to change - error if it appears multiple times or something
use sed to change that line
to append something to a file
check if file exists
grep to ensure it hasn't been appended to already
echo whatever >> file - the double greater than appends to a file
with each of these I would make a backup copy of the file first, just in case something goes wrong
You might want to have a look at the Unified Configuration Interface (UCI) used in Embedded Linux systems. If you have the flexibility to adapt the UCI format for your config files, this is pretty similar to what you are looking for.

showing differences within a line in diff output

This StackOverflow answer has an image of KDiff3 highlighting intra-line differences. Does someone know of a tool which can show the same (ex, via color) on the command line?
Another way to think of this is wanting to diff each difference in a patch file.
I don't know if this is sufficiently command line for your purpose, but vimdiff can do this (even does colour). See for example the image in this related question.
I tried all the tools I found: wdiff, dwdiff, kdiff3, vimdiff to show the difference between two long and slightly different lines. My favourite is diff-highlight (part of git contrib)
it supports diff format - great advantage over tools requiring two files like (dwdiff), e.g. if you need to visualize the output of unit tests
it highlights with black+white or with color if you connect it to colordiff
highlights characterwise - helpful for comparing long lines without spaces (better than wdiff)
Installation
On Ubuntu, you probably already have it as part of git contrib (installed within the git deb package).
Copy or link it into your ~/bin folder from /usr/share/doc/git/contrib/diff-highlight/diff-highlight
Usage example
cat tmp.diff | diff-highlight | colordiff
Result:
Another intuitive way to see all word-sized differences (though not side-by-side) is to use wdiff together with colordiff (you might need to install both). An example of this would be:
wdiff -n {file-A} {file-A} | colordiff
You can optionally pipe this into less -R to scroll through the output (-R is used to show the colors in less).
I had a similar problem and wanted to avoid using vimdiff. I found dwdiff (which is available in Debian) to have several advantages over wdiff.
The most useful feature of dwdiff is that you can customise the delimiters with -d [CHARS], so it's useful for comparing all kinds of output. It also has color built in with the -c flag.
You might be able to use colordiff for this.
In their man page:
Any options passed to colordiff are
passed through to diff except for the
colordiff-specific option 'difftype',
e.g.
colordiff --difftype=debdiff file1
file2
Valid values for 'difftype' are: diff,
diffc, diffu, diffy, wdiff, debdiff;
these correspond to plain diffs,
context diffs, unified diffs,
side-by-side diffs, wdiff output and
debdiff output respectively. Use these
overrides when colordiff is not able
to determine the diff-type
automatically.
I haven't tested it, but the side-by-side output (as produced by diff -y file1 file2) might give you the equivalent of in-line differences.
ccdiff is a convenient dedicated tool for the task. Here is what an example may look like with it:
By default, it highlights the differences in color, but it can be used on a console without color support too.
The package is included in the main repository of Debian:
ccdiff is a colored diff that also colors inside changed lines.
All command-line tools that show the difference between two files fall short in showing minor changes visuably useful. ccdiff tries to give the look and feel of diff --color or colordiff, but extending the display of colored output from colored deleted and added lines to colors for deleted and addedd characters within the changed lines.