Since I reinstalled my ArchLinux distro I get an error when I want to use OpenVPN. Here is the full output:
quentin#QuentinDesktop ~/Documents> openvpn --config ulille-vpn.ovpn
2022-01-04 21:52:15 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2022-01-04 21:52:15 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Options error: --up script fails with '/etc/openvpn/update-systemd-resolved': No such file or directory (errno=2)
Options error: Please correct this error.
Use --help for more information.
Here is the truncated ulille-vpn.ovpn file content (I just truncated the CA certificates):
ignore-unknown-option comp-lzo compress
dev tun
persist-tun
persist-key
cipher AES-256-CBC
tls-client
client
resolv-retry infinite
proto udp
remote vpn-etudiant.univ-lille.fr 443
verify-x509-name "vpn-etudiant.univ-lille.fr" name
auth SHA256
auth-user-pass
comp-lzo
compress lzo
#route-nopull
verb 3
pull-filter ignore "dhcp-option DOMAIN"
dhcp-option DOMAIN univ-lille.fr
dhcp-option DOMAIN univ-lille1.fr
script-security 2
setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
Note that I didn't write this one myself, it is given by my university to access its local network.
I already tried to install the openvpn-update-systemd-resolved AUR package and enable it on systemd but it changed nothing.
How can I fix it ?
Okay, after a quick looking at the configuration file (what I did not think before asking this question), I commented the last 4 lines of the chunk I posted, and it works !
I am sorry for asking this question, I though the config file my university distributes was valid but it looks like it is Fedora/Debian specific, which is kind of weird because it works perfectly fine without these four lines.
I hope this short lifespan topic can help someone else in a similar case ! :^)
I had the very same problem and it was also the config file trying to run up /etc/openvpn/update-systemd-resolved. Seems to be a distro problem as I'm also running arch.
I met a problem when using pintool and itrace,
I use pintool to execute a HelloWorld.exe demo program
pin -t itrace.dll -- HelloWorld.exe
However, the generated "itrace.out" indicate no eips for user code
like this:
0x77e52996
0x77e52998
0x77e52999
0x77e5299a
0x77e5299b
0x77e5299c
0x77e2dd42
0x77e2dd45
0x77e2dd4c
0x77e2dd53
0x77e2dd6d
0x77e23c50
0x77e23c56
0x77e23c59
0x77e23c5b
0x77e23c5d
i try to monitor values with nagios over snmp from my two audiocodes SBCs (M500L).
For these i download two MIBs "AC-ALARM-MIB" + "IP-MIB_rfc4293" from https://github.com/librenms/librenms/tree/master/mibs/audiocodes rename it to .txt at the end and upload it to my ubuntu server in path /usr/share/snmp/mibs/.
Then i try to use the following command in command line.
snmpget -v3 -l authPriv -u xxxxxx -a SHA -A xxxxx -x AES -X xxxxx 123.456.789.100 AcAlarm:acActiveAlarmName
and i get the following output
AcAlarm::acActiveAlarmName = No Such Instance currently exists at this OID
I try to find out the OID from these in MIB Browser - seems like it is " .1.3.6.1.4.1.5003.11.1.1.1.1.5". When i use these OID i get same output.
Anyone has an idea?
SNMP treats all values as being entries in some database. OIDs are used to identify entries in this conceptual database. MIB files allow an SNMP manager to translate OIDs into a human-readable string, with an accompanying textual description.
The issue here is not that the MIB files are bad, or the OIDs are wrong, the problem is that, either the devices that hold this (imaginary) database do not support the entries you are trying to access, or that your user is not authorized to access those entries. A simple way to find out what OIDs are supported would be to do a full walk of the database, using something like snmpwalk <hostname> 1.3.6.1
I have updated my build environment compiler from gcc 5.5.0 to gcc 9.3.0 and noticed coverage calculation performance regression.
It became 10 times slower (5 hours vs 48 hours for whole project).
My investigation shows that in gcov-9 they started to use json format instead of intermediate text format.
This slowed down intermediate gcov-files creation and parsing.
Minimal example below:
> time geninfo --gcov-tool gcov-5 test5/CPrimitiveLayerTest.cpp.gcno
Found gcov version: 5.5.0
Using intermediate gcov format
Processing test5/CPrimitiveLayerTest.cpp.gcno
Finished .info-file creation
real 0m0.351s
user 0m0.298s
sys 0m0.047s
> time geninfo --gcov-tool gcov-9 test9/CPrimitiveLayerTest.cpp.gcno
Found gcov version: 9.3.0
Using intermediate gcov format
Processing test9/CPrimitiveLayerTest.cpp.gcno
Finished .info-file creation
real 0m8.024s
user 0m7.929s
sys 0m0.084s
I didn't find the way to return to old format but maybe there are any workarounds or patches.
P.S. I know about gcov's argument --json-format, but lcov1.15 can process either json format or so-called intermediate text format. At the same time gcov9 can output either json format or so-called logfile format files
Further investigation shows that this is because of lcov 1.15 uses JSON:PP module for json parsing.
Replacing of JSON:PP to JSON:XS (fast parser) gives required speedup.
So I use next commands to reach it:
# patch geninfo to use fast json parser
> sudo sed -i 's/use JSON::PP/use JSON::XS/g' /usr/local/bin/geninfo
# install perl module
> sudo cpan install JSON:XS
The documentation for the Keychain Services API leaves a bit to be desired. One thing that I can't seem to locate are details on accessing the Secure Notes that the Keychain Access app lets you add and edit.
Any insight would be much appreciated. Thanks.
Just to expand on the accepted answer:
Indeed "secure notes" are stored as just specially formatted generic passwords. Thus, if you create a secure note, you can get programmatic access to it using the Keychain Services API: SecKeychainFindGenericPassword() or the security command line tool.
As an example of using security, if you have a secure note named "Testing Note":
You will need to search for "secure notes" and for the title of the note, "Testing Note". The "type" (or desc field) will be "note", and the "service" (or svce field, the name of the keychain entry) will be the actual title of the note. It seems that for every field you specify, it has to be exact, so searching for "Testing *" or "Testing" will not turn up any results for our note.
So you can use this command to search for notes with the type "secure note" and title "Testing Note":
security find-generic-password -C note -s "Testing Note"
And you get as a result:
keychain: "/Users/USERNAME/Library/Keychains/login.keychain"
class: "genp"
attributes:
0x00000007 <blob>="Testing Note"
0x00000008 <blob>=<NULL>
"acct"<blob>=<NULL>
"cdat"<timedate>=0x32303134313231323137333130395A00 "20141212173109Z\000"
"crtr"<uint32>=<NULL>
"cusi"<sint32>=<NULL>
"desc"<blob>="secure note"
"gena"<blob>=<NULL>
"icmt"<blob>=<NULL>
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303134313231323137333130395A00 "20141212173109Z\000"
"nega"<sint32>=<NULL>
"prot"<blob>=<NULL>
"scrp"<sint32>=<NULL>
"svce"<blob>="Testing Note"
"type"<uint32>="note"
To get the password to output as well, you will need to also pass the -g option to the security command, and unless you have explicitly set security as a trusted/allowed program to access that keychain item, it will ask you if you want allow access to a keychain item:
Looking at just the password output (you can use the -w option to only output the "password", or the text of our note, however you don't get the 'decoded' output, just the hex), you get:
security find-generic-password -C note -s "Testing Note" -w
(formatted for clarity)
3c3f786d 6c207665 7273696f 6e3d2231 2e302220 656e636f
64696e67 3d225554 462d3822 3f3e0a3c 21444f43 54595045
20706c69 73742050 55424c49 4320222d 2f2f4170 706c652f
2f445444 20504c49 53542031 2e302f2f 454e2220 22687474
703a2f2f 7777772e 6170706c 652e636f 6d2f4454 44732f50
726f7065 7274794c 6973742d 312e302e 64746422 3e0a3c70
6c697374 20766572 73696f6e 3d22312e 30223e0a 3c646963
....... (and so on)
Not very useful! If we use some python code to decode it: (or any language of your choice)
#!/usr/bin/env python3
import xml.etree.ElementTree as ET
import plistlib, pprint, binascii
# not full hex string for brevity!
hex_data = '''3c3f786d6c2076657273696f6e3d22312e3022206....'''
# decode hex into bytes
xml_bytes = binascii.unhexlify(hex_data)
# create ElementTree object since its an XML PList
ET.fromstring(xml_bytes)
# print out xml
print(ET.tostring(xml_bytes))
# or you can load it straight into a python object using plistlib
plist_dict = plistlib.loads(xml_bytes)
pprint.pprint(plist_dict)
Now we are getting somewhere! The result of decoding it is:
<plist version="1.0">
<dict>
<key>NOTE</key>
<string>12345
abcdefghijklmnopqrstuvwxyz
HELLO WORLD
=)
</string>
<key>RTFD</key>
<data>
cnRmZAAAAAADAAAAAgAAAAcAAABUWFQucnRmAQAAAC43AQAAKwAAAAEAAAAvAQAAe1xy
dGYxXGFuc2lcYW5zaWNwZzEyNTJcY29jb2FydGYxMzQzXGNvY29hc3VicnRmMTYwCntc
Zm9udHRibFxmMFxmc3dpc3NcZmNoYXJzZXQwIEhlbHZldGljYTt9CntcY29sb3J0Ymw7
XHJlZDI1NVxncmVlbjI1NVxibHVlMjU1O30KXHBhcmRcdHg1NjBcdHgxMTIwXHR4MTY4
MFx0eDIyNDBcdHgyODAwXHR4MzM2MFx0eDM5MjBcdHg0NDgwXHR4NTA0MFx0eDU2MDBc
dHg2MTYwXHR4NjcyMFxwYXJkaXJuYXR1cmFsCgpcZjBcZnMyNCBcY2YwIDEyMzQ1XAph
YmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5elwKSEVMTE8gV09STERcCj0pXAp9AQAAACMA
AAABAAAABwAAAFRYVC5ydGYQAAAAXSaLVLYBAAAAAAAAAAAAAA==
</data>
</dict>
</plist>
So we obviously have the plaintext password as the value to the key "NOTE" (as this is how plists store dictionaries), but what is the "RTFD" key? Looking at it in binary gives the impression that its some sort of rtfd file:
b'rtfd\x00\x00\x00\x00\x03\x00\x00\x00\x02\x00\x00\x00\x07\x00\x00\x00TXT.rtf\x01 ......
But saving it as a .rtfd doesn't work, but then I realized that RTFDs saved from TextEdit for example, are bundles! So how does that work... you can't really serialize a bundle to bytes, as its a folder with files inside, but then upon more searching, (I found the Apple Type Code list , and there is "com.apple.rtfd", but also "com.apple.flat-rtfd", which it says is a "pasteboard" format!
So I used a sample application from Apple that shows detailed information about the clipboard/pasteboard. Then you can right click in Keychain access, "copy secure note":
And then if you look at the bytes in ClipboardViewer, you see it matches the un-hexed bytes in the tag in the plist.
Whew! That was a lot longer then I expected.... So in short, a Secure Note is just a generic password, with a title, and the password part being an Apple XML Plist, with the plaintext data, and the data in a pasteboard format suitable for copying to the clipboard with "Copy Secure note to clipboard".
I hope this clears up how Secure Notes are stored, as there is indeed a lack of API functions that access secure notes, and nothing in the official Keychain access API.
I figured out that you can pull the data using the security command line tool. Secure notes are stored as generic passwords with the following characteristics:
class: "genp" - this is the same as a generic password
type<uint32>="note" - you can use this to identify secure notes specifically when searching (using the -C flag).
desc<blob>="secure note" - I don't know that you can search based on this field but it definitely identifies the item as a secure note
0x00000007 <blob>= "Note name" - I don't know if you can get this via the API but you can definitely get it from the command line tool
acct<blob>=<NULL> - This seems to be a common characteristic of secure notes
Use the command security dump-keychain to find all kinds of useful info about the keychain items.
You can grab the value of a keychain secure note using a long chain of commands from the macOS terminal. The snippet below gets the value of a note named "foobar" and saves it to a file called foobar.txt on the user's desktop.
security find-generic-password -C note -s 'foobar' -w | xxd -r -p |
xmllint --xpath "//dict/data/text()" - | base64 --decode |
textutil -stdin -convert txt -output ~/Desktop/foobar.txt