Re: Attempting to configure syslogd for logging doas
Hello, Raf; After creating the doas log file I was able to syslog was able to write messages to the file. I read the man page for newsyslog and have configured it for the doas log. Thank you for you help. Ben Raskin.
RE: size of size_t (diff angle)
Haai,
"Marc Espie" wrote:
>>> You're looking at the wrong type. size_t is very good for what it does.
>>
>> Yes; meproblem is with the 'what it does' part.
>
> It represents memory sizes. It works on anything with a sane
> memory model.
The way meunderstands it, it's just an offset, plain and simple. Which
on a sane machine is indeed of the same type as an address[0].
Unfortunately, C99 does not appear to reflect that. Now, to what degree
(if!) we should respect C99, or take it much seriously at all, is
another matter...
>>> Try uintptr_t
>>
>> Are you proposing a change to struct iovec?
>
> Why should I ? readv works with sizes, so size_t is adequate.
Yes, why should you? That was me implied question. You told me to use
uintptr_t, but that will hardly solve things on the exact problem mewas
working on (medidn't specify what it was, and you didn't ask), unless we
change struct iovec (cue an 'over my dead body' response from theo, and
with respect to compat, he'd be damn right).
> You were mentionning caddr_t earlier. intptr_t and uintptr_t are
> the adequate types for working with addresses. size_t is the adequate
> family for working with sizes.
Me's found that such statements emerge from a shallow understanding of
the nature of C. C doesn't know sizes: indeed, it barely knows indices
and offsets. If sizeof() would have been defined to return the index
of the final byte, instead of the count of bytes, then the C99
definition for size_t would've been pre-empted.
> POSIX kind-of implies readv, which means that both realms tend of
> mesh.
Yes, that's an obvious layer error. C as a language should not be
confused with libc, or UNIX in general. In fact, C and UNIX appear to
only have two concrete things in common: ASCII, and the byte as the
fundamental type. That's it.
> If you're on something where they don't, you're fucked.
Me's never been the type to play it safe. The path forward is not blind
obedience to the ravings of committees, especially those that pretend to
set a universal standard.
> Good luck.
Thanks. Me's decided to ditch the {read,write}v compat wrappers and take
the performance hit. It's all preperation for a real OS, after all:
me'll do it right in there.
> What are you doing asking questions on an OpenBSD list, btw ?
nnx runs on OpenBSD. You must be confusing it with NetNIX, which is the
OS that will eventually emerge.
NetNIX will not have size_t.
Baai,
--zeurkous.
[0] Except, of course, it's an 'offset + 1'. Oops. But that's the least
of the problems if SIZE_MAX is not guaranteed to be the highest
address...
--
Friggin' Machines!
Re: Attempting to configure syslogd for logging doas
On Wed, Feb 26, 2020 at 08:59:40PM GMT, b...@0x1bi.net wrote: > I'm attempting to configure syslogd via syslog.conf. I've added two > lines which log all doas events: > > default configuration here... > > !doas > *.* /var/log/doas > > However, after restarting syslogd and attempting to running commands > through doas, /var/log/doas is not being created. > > Am I missing something? Is this exclusive to doas? Thank you in > advance. > > Ben Raskin. > Hi Ben, After syslogd(8) manual page: CAVEATS syslogd does not create files, it only logs to existing ones. So, in general, after you make your changes to syslog.conf(5), i.e.: # install -m 0600 /dev/null /var/log/doas && rcctl reload syslogd Also, don't forget about newsyslog(8)! BTW, in case you aren't aware, doas usage is already logged into /var/log/secure. Regards, Raf
spamDB - blacklist mode
Hi misc, Questions: Does the spamDB play a role at all in pure Black listing mode ? Does the spamDB only get created/configured when running in Normal/Grey mode ? Does is require Manual creation ? Issue: When Attempting to review SPAMDB entries i get an error: spamdb: cannot open /var/db/spamd for reading: No such file or directory Setup: My aim is to just trap & annoy spammers and build my own blacklist. Connection to this host will only ever tarpit and log. (it's the last mx record) With a fresh install of 6.6 deployed, i have setup PF and SPAMD in pure blacklist mode, following the manpage and various guides from PeterH etc.. $ grep spamd /etc/rc.conf.local spamd_flags= spamd_black=YES pf.conf # == SPAMD redirect == pass in on $ext_if proto tcp to any port smtp \ divert-to 127.0.0.1 port spamd Tarpit is working, logging is working: Feb 26 10:01:15 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 6 seconds. Feb 26 10:01:20 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 5 seconds. Feb 26 10:01:25 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 5 seconds. Feb 26 10:01:30 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 5 seconds. Feb 26 10:01:36 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 6 seconds. Feb 26 10:01:42 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 6 seconds. Feb 26 13:00:20 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 13 seconds. Feb 26 13:00:30 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 12 seconds. Feb 26 13:00:40 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 12 seconds. Feb 26 13:38:28 myhost spamd[3205]: xx.xx.xx.xx: disconnected after 12 seconds. I have also run /usr/libexec/spamd-setup with default config. (no errors) thanks in advance. -sub
Re: size of size_t (diff angle)
On Wed, Feb 26, 2020 at 11:01:56PM +0100, zeurk...@volny.cz wrote: > Haai, > > "Marc Espie" wrote: > > On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz wrote: > > > > You're looking at the wrong type. size_t is very good for what it does. > > Yes; meproblem is with the 'what it does' part. It represents memory sizes. It works on anything with a sane memory model. > > Try uintptr_t > > Are you proposing a change to struct iovec? Why should I ? readv works with sizes, so size_t is adequate. You were mentionning caddr_t earlier. intptr_t and uintptr_t are the adequate types for working with addresses. size_t is the adequate family for working with sizes. POSIX kind-of implies readv, which means that both realms tend of mesh. If you're on something where they don't, you're fucked. Good luck. What are you doing asking questions on an OpenBSD list, btw ?
RE: size of size_t (diff angle)
Haai, "Marc Espie" wrote: > On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz wrote: > > You're looking at the wrong type. size_t is very good for what it does. Yes; meproblem is with the 'what it does' part. > Try uintptr_t Are you proposing a change to struct iovec? --zeurkous. -- Friggin' Machines!
RE: size of size_t (diff angle)
Haai, "Anders Andersson" wrote: > On Tue, Feb 25, 2020 at 12:14 PM wrote: >> >> First of all, let us reflect upon the definition of size_t in C99. >> >> > size_t >> > which is the unsigned integer type of the result of the sizeof >> > operator; >> >> That's not very specific. It kind-of implies that SIZE_MAX (defined >> later in the standard) is the largest possible offset, but not >> necessarily the largest possible address. This reeks of i86 real mode >> semantics, obsolete (for general-purpose machines) already when the >> PDP-11 was new. > > I think it's pretty clear, size_t is for the size of objects, not for > offsets or pointers. At least in C, the difference between sizes, offsets, and addresses are semantic in nature. Even B, as meunderstands, treats memory as a flat array (just of words instead of bytes). > The C standard frowns upon mixing up pointers and > integers, to much grief from low-level developers. Menoticed that too. Given the nature and background of C, it's pretty weird (not to say inappropriate) for 'the standard'(tm) to do so. >> Is SIZE_MAX guaranteed to *not* be greater than the highest address? > > I'm almost certain that C99 offers no such guarantees, since a pointer > to a float does not have to be the same size as a pointer to int, for > example. Maybe if you're being a little more specific. There are some > exceptions for void * and char *. > > In fact, the standard only *recommends* that implementations keep > SIZE_MAX as small as possible but not smaller. Since it is only a > recommendation, it can be inferred that the standard acknowledges that > an implementation with SIZE_MAX > highest address is valid. Mesupposes that's tolerable, as long as sizeof() indeed never returns a value greater than the largest address... mehas observed no such guarantee either, however. > "The types used for size_t and ptrdiff_t should not have an integer > conversion rank greater than that of signed long int unless the > implementation supports objects large enough to make this necessary." Yes, menoticed. Strange for the standard to suddenly group sizes and addresses (address "diffs" even!) together. Quite schizophrenic if you ask me... > Or my interpretation: "Just because there is now a new and fancy > 64-bit long long in C99 doesn't mean that you should make size_t a > long long just because you can, because it's pointless if your > compiler/target only has a 32-bit address space." The issue mebumped into was that SIZE_MAX being an arbitrary value, with no specified relation to the highest address, makes some compat code pretty messy. Hence mehoped that there was some kind of guarantee; megot the answer mefeared. Thanks, your answer was quite helpful. Baai, --zeurkous. -- Friggin' Machines!
Same result (Re: build error on octeon, 6.6)
Hi misc, I got the same libLLVM error message "c++: error: unable to execute command: Segmentation fault" after about 3 days since "make build". I tried twice and did not use any external drives. I have 16GB USB stick inside with - 512 MB / - 512 MB swap - 1GB /tmp - 1GB /var - 10GB /usr - the rest is for /home At the time of the failure the /usr was about 50% full, I have had no problems in building the kernel and patches. -pekka- On 16.11.2019 2.22, Christian Groessler wrote: Hi, On 2019-11-11 12:18, Christian Groessler wrote: Now I'm going to rebuild again, capturing the "make" output, and try to replicate the problem manually. Interestingly, this time the build fails at a later stage. c++ -O2 -pipe -fomit-frame-pointer -std=c++11 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wdelete-non-virtual-dtor -Wno-comment -MD -MP -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Analysis -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Analysis -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/BinaryFormat -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Bitcode -I/include/llvm/CodeGen -I/include/llvm/CodeGen/PBQP -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/IR -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms/Coroutines -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/ProfileData/Coverage -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/CodeView -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/DWARF -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/MSF -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/PDB -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Demangle -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/ExecutionEngine -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/IRReader -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms/InstCombine -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/Transforms/InstCombine -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/LTO -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Linker -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/MC -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/MC/MCParser -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms
Re: PPTP NAT passthrough
This appears to be actively maintained. https://sourceforge.net/projects/pptpclient/ On 02/25/20 12:15, Szél Gábor wrote: Dear @misc Our customer need more parallel outgoing PPTP session. I know PPTP is no security VPN, but our client not have any options. (our customer remote partner accept only PPTP VPN ...) OpenBSD PF can't use parallel PPTP session. First session is NAT-ed, but second session is broken. I know OpenBSD not supported PPTP NAT passthrough. I found two, very old PPTP proxy for openbsd: * https://github.com/crvv/pptp-proxy This is ftp-proxy fork(?) * https://sourceforge.net/projects/frickin/ frickin 1.x working only fix remote PPTP address, not good for me. frickin 2.x (beta) not compiled on oBSD 6.6. pptp-proxy is compiled, and started, but not working. We tested very simple pf.conf (NAT, and some rules) pass in quick log on $int_if proto gre from any to ! $int_if:0 rdr-to 127.0.0.1 pass in quick log on $int_if proto tcp from any to ! $int_if:0 port 1723 rdr-to 127.0.0.1 port 2317 pptp-proxy is accepted session, but not working. (in tcpdump only 2 outgoing, 1 inbound packet found) Does anyone know a working solution for PPTP NAT passthrough? In openbsd based securityrouter.org firewall a found PPTP-Proxy support: https://securityrouter.org/wiki/Comparison But I don't know what to use.
Attempting to configure syslogd for logging doas
I'm attempting to configure syslogd via syslog.conf. I've added two lines which log all doas events: default configuration here... !doas *.* /var/log/doas However, after restarting syslogd and attempting to running commands through doas, /var/log/doas is not being created. Am I missing something? Is this exclusive to doas? Thank you in advance. Ben Raskin.
IEEE 754 floating point, POSIX, C: Why are OpenBSD's logb and logbf wrong?
Hello, I am discussing the OpenBSD logb and logbf from the mathematical part of the C standard library, the same which were imported from NetBSD. They currently return constants for subnormal inputs. As far as I understand, this is not only not very useful for doing math, it also conflicts with POSIX/SUS and the C standard and the established practice of what other libraries are doing: FreeBSD libm, openlibm, Go(lang) math library, I think even OpenBSD's ilogb all do the right thing. If a fix is wanted, I think OpenBSD's licensing requirements permit simply taking the code from FreeBSD or openlibm (all of those have shared ancestors, so merging should be quite easy). On the other hand, the man page for logb (also left over from NetBSD) says "These functions allow users to test conformance to IEEE Std 754-1985. Their use is not otherwise recommended.", so it could be that logb(f) are wrong on purpose? Regards, Neven Sajko
Re: pass 'password manager' problem
On 26.02.2020 10:57, Andreas Kusalananda Kähäri wrote:
On Wed, Feb 26, 2020 at 09:37:53AM +, Shadrock Uhuru wrote:
> > ---
> >
> > shadrock
Hi
yes i have gpg2 installed
gpg-agent.conf has cat .gnupg/gpg-agent.conf
default-cache-ttl 300
max-cache-ttl 99
and i've added export GPG_TTY=$(tty) ~/.profile
but still no joy.
shadrock
Hi,
Do you *also* have gpg installed? If I remember correctly, pass tries
to use gpg rather than gpg2 if gpg is installed when installing pass.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Hi yes i also have gpg installed,
i see this at the beginning of the pass script :-
GPG_OPTS=( $PASSWORD_STORE_GPG_OPTS "--quiet" "--yes"
"--compress-algo=none" "--no-encrypt-to" )
GPG="gpg"
export GPG_TTY="${GPG_TTY:-$(tty 2>/dev/null)}"
which gpg2 &>/dev/null && GPG="gpg2"
[[ -n $GPG_AGENT_INFO || $GPG == "gpg2" ]] && GPG_OPTS+=( "--batch"
"--use-agent" )
which looks like gpg2 is used if it is installed.
shadrock
smime.p7s
Description: S/MIME cryptographic signature
Re: "not MAP_STACK" message in dmesg / system message buffer
On Tue, Feb 25, 2020 at 08:30:11PM -0500, Andre Smagin wrote:
> Hello.
>
> While prototyping something in C, I made a mistake with
> pre-processor macros, which I narrowed down to this:
>
> int
> main()
> {
> char *test[10][2097152] = { { 0 } };
> }
>
> Running it results in
> $ ./a.out
> Segmentation fault (core dumped)
>
> and it also logs it in dmesg as
>
> Feb 25 20:05:49 hamlet /bsd: [a.out]52048/372328 sp=7f7ff5fd4150 inside
> 7f7fff7d5000-7f7d5000: not MAP_STACK
> Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside
> 7f7fff7e7000-7f7e6000: not MAP_STACK
> Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside
> 7f7fff7db000-7f7db000: not MAP_STACK
>
> I have not seen a segfaulting program being logged in system
> message buffer before. Is it expected behaviour?
> Just curious, the message was a bit confusing.
The stack has never been infinite. Allocate too much, run into other issues.
ulimit -a will already tell you about stack size limits.
Baring that, well, running into already allocated memory will hose you.
No further test necessary since MAP_STACK entered the OS (that's sickeningly
beautiful btw)
Re: size of size_t (diff angle)
On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz wrote: > Haai, > > The definition of size_t keeps biting me. > > Some background: in nnx, me's been using the equiv of caddr_t for > counts. This works well; yet, while writing against existing code that > uses size_t, an issue has surfaced. > > First of all, let us reflect upon the definition of size_t in C99. > > > size_t > > which is the unsigned integer type of the result of the sizeof > > operator; > > That's not very specific. It kind-of implies that SIZE_MAX (defined > later in the standard) is the largest possible offset, but not > necessarily the largest possible address. This reeks of i86 real mode > semantics, obsolete (for general-purpose machines) already when the > PDP-11 was new. > > POSIX is even less helpful: > > > size_t > > Used for sizes of objects. > > (Let me note in passing that medisapproves of the significant overlap > between C99 and POSIX, and the shameless disregard, in both, of the > byte-oriented nature of UNIX and C). You're looking at the wrong type. size_t is very good for what it does. Try uintptr_t
Re: What TERM fixes Emacs?
On Mon, Feb 24, 2020 at 09:35:21PM -0800, Emilia wrote: > > > It is impossible to use Emacs on OpenBSD Terminal (no X). > > Look at this screenshots: > > On Linux / macOs -- this same version of Emacs and org-mode would > display this file with colors etc. As stuart said, pccon is the best fit. For a more elaborate answer: choosing a default TERM value for the console is complicated. The main issue being that a lot of the time, you will ssh into another machine that probably doesn't run the same operating system, and thus doesn't necessarily have the same termcap database. So, the default choice in OpenBSD is to have a default value that's very safe (vt220 have been around forever) so that you can login about anywhere. ... whereas pccon is way more recent and specific, and thus will probably hose you when you try to login on some old machines. (these days, new OS versions will all use the same termcap source, so you're probably safe on anything released over the past 5 years)
Re: pass 'password manager' problem
Date: Mon, 24 Feb 2020 14:11:19 - (UTC) As far as I have seen in the pass script, --batch mode is oly invoked if you are running a gpg agent or are running gpg2. Do you have gpg2 installed? Do you have a gpg agent configured? You may need to include the following line in your ~.profile : export GPG_TTY=$(tty) Shadrock Uhuru wrote: [-- text/plain, encoding 8bit, charset: utf-8, 61 lines --] Hi From: Rubén Llorente To: misc@openbsd.org Subject: Re: pass 'password manager' problem Date: Fri, 21 Feb 2020 16:22:37 - (UTC) Do you have a ~.gnupg/gpg.conf ? Pass works fine for me. Shadrock Uhuru wrote: [-- text/plain, encoding 7bit, charset: utf-8, 6 lines --] running 'pass username' returns "gpg: Sorry, we are in batchmode - can't get input", am i missing a piece of software or setting ? shadrock yes i have the following cat ~/.gnupg/gpg.conf use-agent pinentry-mode loopback personal-cipher-preferences CAMELLIA256 AES256 AES192 AES CAST5 # personal-cipher-preferences AES256 AES192 AES CAST5 CAMELLIA192 # BLOWFISH TWOFISH CAMELLIA128 3DES personal-digest-preferences SHA512 SHA384 SHA256 SHA224 personal-compress-preferences BZIP2 ZIP ZLIB default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed cert-digest-algo SHA512 digest-algo SHA256 s2k-mode 3 s2k-digest-algo SHA512 s2k-cipher-algo AES256 s2k-count 1015808 charset utf-8 fixed-list-mode no-greeting no-secmem-warning no-comments no-emit-version keyid-format 0xlong list-options show-uid-validity verify-options show-uid-validity keyserver-options import-clean-sigs import-clean-uids export-clean-sigs export-clean-uids keyserver hkp://hkps.pool.sks-keyservers.net keyserver-options auto-key-retrieve keyserver-options no-honor-keyserver-url escape-from-lines bzip2-compress-level 9 compress-level 9 with-fingerprint --- shadrock Hi yes i have gpg2 installed gpg-agent.conf has cat .gnupg/gpg-agent.conf default-cache-ttl 300 max-cache-ttl 99 and i've added export GPG_TTY=$(tty) ~/.profile but still no joy. shadrock
Re: Trusted Boot with OpenBSD
On Mon, Feb 24, 2020 at 03:22:28PM +0100, Julius Zint wrote: boot(8) supports the machine specific command "tpm". This allows a user to: 1: read the current contents of the Platform Control Registers (PCR) with the "pcr" parameter machine tpm p[cr] 2: seal a user supplied secret to the current PCR values and store it in the second block on a disk, that can be altered via a parameter. WARNING: If there is any other data in this block, it will be overwritten without asking again. machine tpm s[eal] secret [DiskNumber] 3: unseal a previously sealed secrent and display it to the user. This command just reads the second block of the disk that can be specified by the user and unseals it via the TPM machine tpm u[nseal] [DiskNumber] I hope you are enjoying your (well-earned) vacation. I can't tell from the instructions how the FDE encryption key is stored -- do we manually seal it to the TPM and then manually unseal and copy/paste it every time we boot? Or is it assumed the user will write a script to handle this -- a script which itself will have to be measured by the TPM?
Re: Determining which patches a snapshot contains
On 2020-02-25, Jonathan Schleifer wrote: > Fair enough - I can understand you don't want to give any guarantees for > snapshots. > > I guess it's fair to assume that snapshots are only built from full commits > and not partial commits? In this case then, I guess I should be fine. Snapshots can be built with various uncommitted/WIP diffs, and you can only tell approximately when the tree is from. If you want more guarantees than this I would recommend following release(8).
