Hi,
I'm sitting on a patch that adds still more str_*_sensitive()
functions but I'm getting the feeling that it is both excessive and
deficient. For instance, consider:
str_endpoints_sensitive(local, remote) 1.2.3.4:0 -ICMP-> 4.3.2.1:8
str_endpoints_sensitive(remote, local) 4.3.2.1:8
I've just pushed a change making ip_address and ip_endpoint distinct.
- an address is just that 0.0.0.0 or ::
- ipv4 or ipv6
- an endpoint is everything else needed to get a packet to travel from
one machine to another:
- address
- protocol
- "port"
On Tue, 9 Feb 2021 at 22:50, Paul Wouters wrote:
>
> On Tue, 9 Feb 2021, Andrew Cagney wrote:
>
> > My understanding of the kernel's opportunistic code is that the
> > following happens:
>
> I think you need to separate ondemand and opportunistic.
>
>
My understanding of the kernel's opportunistic code is that the
following happens:
- something tries send a packet to LOCAL
- the packet is captured and the all the details - version, address,
protocol [and port when applicable], ... are all provided to pluto
- the details are formed into
but real logging code should not, it should be testing NEVER_NEGOTIATE(policy)
- it seems that NEVER_NEGOTIATE(policy) implies ike_version==0; I'm
left wondering if one is redundant
> Sent from my iPhone
>
> > On Feb 6, 2021, at 09:06, Andrew Cagney wrote:
> >
> > New commits:
I've renamed the 9p mount swansource->source so it is consistent with
the other mounts (pool<->/pool testing<->/testing). Having it
consistent means less places to screw up when generating the
systemd/fstab mount files.
This likely means the kvms need a rebuild (aka make kvm-demolish).
I'm looking at kvm snapshots as a way to further speed up testing -
think sub-second domain creation. However there's a catch:
- the snapshot can't contain anything strange, such as /testing, mounted
This means that /testing needs to be "manually" mounted after the
domain is created. I can see
hangs), which is something that should be
handled cleanly. Ulgh.
Once all these leaks are gone, I can add running refcnt.awk to the
post mortem - unlike the leak code, it can detect Pluto leaking NSS
objects.
On Tue, 17 Nov 2020 at 17:16, Andrew Cagney wrote:
>
> FYI,
>
> On Mon,
On Mon, 4 Jan 2021 at 11:06, Antony Antony wrote:
>
> On Sun, Jan 03, 2021 at 11:54:30AM -0500, Paul Wouters wrote:
> > On Sun, 3 Jan 2021, Andrew Cagney wrote:
> >
> > > Subject: [Swan-dev] what is INTERFACE_IP / ifaceip / interface-ip= for?
> >
> > > I
ttoaddr() contains:
- if (err && af != AF_INET)
- err = tryname(src, srclen, nultermd, AF_INET6, af, dst);
- if (err && af != AF_INET6)
- err = tryname(src, srclen, nultermd, AF_INET, af, dst);
so, for AF==AF_UNSPEC, it will
On Sun, 3 Jan 2021 at 09:31, Andrew Cagney wrote:
>
> I suspect it has something to do with XFRMI. As best I can, in the
> current code, it is simply being passed to up-down scripts as
> INTERFACE_IP=...?
> While the name ifaceip leads me to think it's got something to do
I suspect it has something to do with XFRMI. As best I can, in the
current code, it is simply being passed to up-down scripts as
INTERFACE_IP=...?
While the name ifaceip leads me to think it's got something to do with
the host interfaces, I suspect it is connected to the XFRMI client
interface IP
One of the quirks of ttosubnet() is that it will parse:
1.2.3.0/24:10
(I suspect the idea is to allow 1.2.3.4/32:10, i.e., a selector with
one address and one port)?
So when, if ever, is this valid? I couldn't find it being used in
test cases (at least the pattern /[0-9]*: didn't match).
Shorter? Yes.
Simpler? No.
const struct ip_info *lt = address_type(l);
const struct ip_info *rt = address_type(r);
- if (lt == NULL || rt == NULL) {
- /* AF_UNSPEC/NULL are never equal; think NaN */
- return false;
- }
- if (lt != rt)
On Mon, 28 Sept 2020 at 22:49, Andrew Cagney wrote:
>
>
>
> On Mon, 28 Sep 2020 at 21:53, Paul Wouters wrote:
>>
>> On Mon, 28 Sep 2020, Andrew Cagney wrote:
>>
>> > I'm planning on removing the sanitizer ipsec-auto-up.n.sed.
>>
>> I und
I just updated some tests to expect the output from a 5.9 kernel - if
you rebuild the test rpm's that is what is installed.
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
FYI, the code uses popen(), which execs:
/bin/sh -c ...TELMATE_SESSION_KEY=...
so anyone with local access can potentially see the key.
On Mon, 30 Nov 2020 at 13:42, Anthony DeRobertis
wrote:
>
> Quick background, on our client devices, authentication is done via a
> separate program, which
On Fri, 27 Nov 2020 at 15:36, Andrew Cagney wrote:
>
> On Fri, 27 Nov 2020 at 12:44, Paul Wouters wrote:
> >
> > On Wed, 25 Nov 2020, Andrew Cagney wrote:
> >
> > > Here's the current status.
> > >
> > > The standard log primitive
Here's one for the paint shed (I got a really good price on all the
second hand bikes):
I've made the add connection error format consistent adopting:
west # ipsec auto --add westnet-eastnet-ah
036 connection "westnet-eastnet-ah": failed to add connection: AH
integrity algorithm 'des' is not
On Fri, 27 Nov 2020 at 12:44, Paul Wouters wrote:
>
> On Wed, 25 Nov 2020, Andrew Cagney wrote:
>
> > Here's the current status.
> >
> > The standard log primitive is:
> >
> > log_message(RC_FLAGS, logger, FMT, ...)
>
> > but this is all very
I replaced calls with a custom char_is*(char) - our code deals with
octet sized characters in memory not EOF and int from fgetc().
See hunkcheck.c for how it is tested.
While I don't particularly like this solution I also don't partially
like :
- the current locale can affect behaviour (yes
Here's the current status.
The standard log primitive is:
log_message(RC_FLAGS, logger, FMT, ...)
where:
RC_FLAGS specifies:
whack's RC code; typically RC_LOG
which streams - WHACK, ERROR, LOG, DEBUG - to send message
(blank is equivalent to WHACK+LOG)
but unless something
FYI,
On Mon, 16 Nov 2020 at 09:38, Andrew Cagney wrote:
>
> https://testing.libreswan.org/v4.1-178-gf93f336eb1-main
>
> 4 IntAuth_*_I
> 4 IntAuth
These are from intermediate exchange.
> 2 heap logger prefix
> 2 heap logger
these are from algpars
IntAuth_*_I
ikev2-intermediate-02-psk IntAuth
ikev2-intermediate-02-psk IntAuth_*_I
ikev2-intermediate-02-psk IntAuth_*_I
ikev2-intermediate-02-psk IntAuth
On Fri, 30 Oct 2020 at 09:12, Andrew Cagney wrote:
>
> This is an updated list I extracted from
> https://testing.libreswan.or
On Thu, 12 Nov 2020 at 16:18, Sahana Prasad wrote:
>
>
>
> On Thu, Nov 12, 2020 at 9:00 PM Andrew Cagney wrote:
>>
>> On Thu, 12 Nov 2020 at 13:16, Sahana Prasad
>> wrote:
>> >
>> > Hello Andrew,
>> >
>> > The author of the in
s that
> should change too)
>
>
> Added Yulia in case I have missed any details.
>
>
> Thank you,
>
> Regards,
>
> Sahana Prasad
>
>
> On Mon, Nov 9, 2020 at 4:07 PM Andrew Cagney wrote:
>>
>> thanks!
>>
>> As an aside. I'm curren
Prasad wrote:
>
> Hello Andrew,
> Thanks for the analysis.
>
> I'll get back to you on this one with more details.
>
> Thank you,
> Regards,
> Sahana Prasad
>
> On Wed, 4 Nov 2020, 20:56 Andrew Cagney, wrote:
>>
>> The immediate problem is that the int
We're close to zero leaks. The next ones are:
orphan shunt
bare shunt
I'm still trying to understand their lifetime. For instance, what
triggers them being created, replaced, or deleted.
Here's my starting point:
- something (connection?) causes an acquire to be inserted in the
kernel (so
The immediate problem is that the intermediate exchange is leaking the
local dh secret. However there seems to be more going on - someone
familiar with intermediate code should probably take a look.
- the initiator, on receipt of an IKE_SA_INIT responce calls,
ikev2_parent_inR1outI2() which
host pair
On Wed, 28 Oct 2020 at 07:59, Andrew Cagney wrote:
>
> (in case you missed the commits)
> The changes to, at the end of every test and regardless of final.sh,
> shutdown pluto then check for leaks and cores have been pushed to
> https://testing.libreswan.org/
> I've
On Wed, 28 Oct 2020 at 23:14, Paul Wouters wrote:
>
> On Wed, 28 Oct 2020, Andrew Cagney wrote:
>
> > in ikev2-x509-20-multicert-rightid-san-wildcard, this causes right to
> > leak "issuer ca":
> > https://testing.libreswan.org/v4.1-83-g9d775e57d4-main/ikev2-x
(in case you missed the commits)
The changes to, at the end of every test and regardless of final.sh,
shutdown pluto then check for leaks and cores have been pushed to
https://testing.libreswan.org/
I've also pushed a few memory-leak fixes (one in IKEv1's aggressive
initiator code seems to go back
On Tue, 27 Oct 2020 at 10:44, Paul Wouters wrote:
>
> On Tue, 27 Oct 2020, Andrew Cagney wrote:
>
> > I've encountered another race. Tests such as algparse-02-fips, which
> > start pluto only to immediately shut it down, can leak:
> >
> > leak-detective enabled
at 21:16, Andrew Cagney wrote:
>
> On Wed, 7 Oct 2020 at 19:53, Paul Wouters wrote:
> >
> > Run ‘ss’ or netstat and look for the listen without the whack ?
>
> I changed it to 'whack --impair none'. These all though have the same
> problem - they wait for pluto to
On Sat, 17 Oct 2020 at 05:51, Antony Antony wrote:
>
> I think fix f9fada7234b is worth a closer look.
The source of the change is an IETF discussion around eid5247. I'm
not sure if that is public.
The upshot is that while these numbers all seem to be drawn from a
common table, they're not.
there's code in rcv_whack.c that shuts down pluto when .magic is
unknown. I'm adding this comment:
* XXX:
*
* I'm guessing to ensure upgrades work and a new whack can
* shutdown an old pluto, the code below reads .whack_shutdown
* regardless of the value of .magic.
On Fri, 16 Oct 2020 at 09:47, Paul Wouters wrote:
>
> On Fri, 16 Oct 2020, Tuomo Soini wrote:
>
> >> There were thoughts about removing IPSECBASEVERSION alltogether, and
> >> setting it now to something like "4.1dev".
> >
> > Just 4.1 - the next version
>
> That would be misleading though, you
Now that 4.0 is out ...
I've removed the end from final.sh BUT **/NOT/** nicinit.sh
(which is what this discussion was about).
On Wed, 29 Jan 2020 at 04:28, Paul Wouters wrote:
>
> On Wed, 29 Jan 2020, Antony Antony wrote:
>
> >> I'm happy to do this after the 3.30 release.
> >>
> >>
The two functions have a basic but subtle difference - everything is
reversed. For instance:
- on the way out its encryption then prf; on the way in it is prf then
encryption
- on the way out it's aead(true); on the way in it's aead(false) (and
at some point that was wrong)
- on the way out SA
>
> > On Oct 7, 2020, at 17:14, Andrew Cagney wrote:
> >
> > The stray 'whack --listen' is coming from wait-until-pluto-started,
> > for instance:
> >
> > | whack: delete 'clear'
> > | whack: connection 'clear'
> > | whack: delete 'clear-or-priva
route
which means, in addition to screwing around with addconn, it isn't
waiting for addconn to finish.
Thoughts on making this more robust?
On Tue, 29 Sep 2020 at 21:45, Andrew Cagney wrote:
>
> I'm trying to understand this diff
> https://testing.libreswan.org/v3.30-1853-gc4b35c42cb-ma
On Tue, 6 Oct 2020 at 21:37, Paul Wouters wrote:
>
> On Tue, 6 Oct 2020, Andrew Cagney wrote:
>
> >> We have had that situation for many years now (like 5-7 or so)
> >>
> >> I placed back aliaes for virtual_private and plutostderrlog because
> >> t
On Tue, 6 Oct 2020 at 14:11, Paul Wouters wrote:
>
> On Tue, 6 Oct 2020, Andrew Cagney wrote:
>
> > I wonder if it would be prudent, in 4.0, to provide either an
> > alias+warning, or more a more specific error stating the replacement.
> > We've already seen one bug r
I wonder if it would be prudent, in 4.0, to provide either an
alias+warning, or more a more specific error stating the replacement.
We've already seen one bug report related to this where the user was
simply following an example we provide.
(yes I know I started the trend)
FYI,
I've re-enabled the upstream kernel for f32. It seems to be working with
TCP. You'll want to:
- remove any KVM_KERNEL*= stuff from Makefile.inc.local
- gmake kvm-upgrade
Andrew
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
I'm trying to understand this diff
https://testing.libreswan.org/v3.30-1853-gc4b35c42cb-main/newoe-25-cat-2/OUTPUT/road.console.diff
-000 "block": newest ISAKMP SA: #0; newest IPsec SA: #0; conn serial: $9;
+000 "block": newest ISAKMP SA: #0; newest IPsec SA: #0; conn serial: $5;
Pluto is
On Mon, 28 Sep 2020 at 15:11, Antony Antony wrote:
> On Mon, Sep 28, 2020 at 12:44:03PM -0400, Andrew Cagney wrote:
> > I'm planning on removing the sanitizer ipsec-auto-up.n.sed. It removes
> what I
> > consider to be important contextual information from console.txt.
ut. There's remove anything non-traffic related,
notably the ID, from the topology.
>
> After 4.0 :)
>
M'kay.
> Sent from my iPhone
>
> > On Sep 26, 2020, at 10:28, Andrew Cagney
> wrote:
> >
> >
> > I'd like to refine this ascii art of the topology
I'm planning on removing the sanitizer ipsec-auto-up.n.sed. It removes
what I consider to be important contextual information from console.txt.
For instance, consider this output:
--- MASTER/testing/pluto/nss-cert-crl-03-strict/west.console.txt
+++
I'd like to refine this ascii art of the topology a little
-> I think there should be spaces around the "..." so that it is visually
easier to spot the left and right sides
(using === for the "tunnel" in the middle and --- on the edges would have
been so much nicer, sigh)
-> which brings to ...
On Thu, 24 Sep 2020 at 22:37, Paul Wouters wrote:
> On Thu, 24 Sep 2020, Andrew Cagney wrote:
>
> > Once ddns resolves a name it updates .host_addr (from AF_UNSPEC to a
> valid address).
> > This, in turn, can update .client to .host_addr/32.
> > And updating .clie
On Thu, 24 Sep 2020 at 20:56, Paul Wouters wrote:
> On Thu, 24 Sep 2020, Andrew Cagney wrote:
>
> > -> the config file has right[host]=%any
> > -> update_ends_from_this_host_addr() (nee default_end()) sees this and
> does nothing (right.end.client.maskbits==0)
>
This:
https://testing.libreswan.org/v3.30-1791-gd106052012-main/ikev1-hostpair-01/OUTPUT/east.console.diff
Comes from: connections: don't update an end when .host_addr is 0.0.0.0
https://github.com/libreswan/libreswan/commit/a739eaff972135b268a139c54b37e0f366a6ad02
In case the cause isn't
nce
fixed it.
> On Sep 24, 2020, at 13:08, Andrew Cagney wrote:
>
>
> Some of the old code used lsw_cp_file() some did not. Do you have a
> mysterious /etc/strongswan directory?
>
> On Thu, 24 Sep 2020 at 12:19, Paul Wouters wrote:
>
>>
>> I ended up a few time
(src, dst, follow_symlinks=follow_symlinks)
>File "PATH/lib64/python3.9/shutil.py", line 261, in copyfile
> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
> PermissionError: [Errno 1] Operation not permitted: '/etc/ipsec.conf'
> east #
>
>
> bisecting this
I pushed:
commit d106052012c6a7b7a5d65e25e9c9fe0c32e34c1d (HEAD -> main, origin/main,
origin/HEAD)
Author: Andrew Cagney
Date: Wed Sep 23 19:36:49 2020 -0400
connections: call update_ends_from_this_host_addr() from
connection_check_ddns1()
Replace "a small bit of c
On Tue, 22 Sep 2020 at 23:09, Paul Wouters wrote:
> On Tue, 22 Sep 2020, Andrew Cagney wrote:
>
> > On Tue, 22 Sep 2020 at 21:36, Paul Wouters wrote:
> > On Tue, 22 Sep 2020, Andrew Cagney wrote:
> >
> > > Now that the parser can accept -NONE- -,
On Wed, 23 Sep 2020 at 02:18, Antony Antony wrote:
> On Tue, Sep 22, 2020 at 04:14:34PM -0400, Andrew Cagney wrote:
> > Regardless of the end, a line like:
> >leftrsasigkey=
> >leftrsasigkey2=...
> > will always add public keys like:
> >(g
On Tue, 22 Sep 2020 at 21:36, Paul Wouters wrote:
> On Tue, 22 Sep 2020, Andrew Cagney wrote:
>
> > Now that the parser can accept -NONE- -, should "NONE" be
> included when logging those proposals? For instance:
> >
> > OLD:
> > algparse -v2 'ike=
On Tue, 22 Sep 2020 at 14:59, Paul Wouters wrote:
> On Tue, 22 Sep 2020, Andrew Cagney wrote:
>
> > I pushed:
> >
> > commit 19949fe10a5ad797937ba97a3cfda9c02e59930d (origin/main,
> origin/HEAD)
> > Author: Andrew Cagney
> > Date: Tue Sep 22 13:10:
Regardless of the end, a line like:
leftrsasigkey=
leftrsasigkey2=...
will always add public keys like:
(generated?) leftid / leftrsasigkey
(generated?) leftid / leftrsasigkey2
to the list of raw public keys. Left will then try all raw public keys
matching .
The problem is that the
Now that the parser can accept -NONE- -, should "NONE" be
included when logging those proposals? For instance:
OLD:
algparse -v2 'ike=aes_gcm-sha1-dh21'
AES_GCM_16-HMAC_SHA1-DH21
algparse -v2 'ike=aes_gcm_16-none-hmac_sha1-dh21'
AES_GCM_16-HMAC_SHA1-DH21
NEW:
algparse -v2
I pushed:
commit 19949fe10a5ad797937ba97a3cfda9c02e59930d (origin/main, origin/HEAD)
Author: Andrew Cagney
Date: Tue Sep 22 13:10:44 2020 -0400
testing: drop machine=... in machine xml files
Suspect it is causing:
error: Failed to start domain w5.nic
error: internal
libreswan.org from
to 192.1.2.23
| connect_to_host_pair: 192.1.2.45:500 192.1.2.23:0 -> hp@(nil): none
default_end() should have been re-called.
On Mon, 21 Sep 2020 at 14:34, Andrew Cagney wrote:
>
>
> On Mon, 21 Sep 2020 at 13:53, Paul Wouters wrote:
>
>> On Sun, 20 Sep 202
- hvm
+ hvm
I suspect this is connected to:
error: Failed to start domain w5.nic
error: internal error: process exited while connecting to monitor:
2020-09-21T22:52:01.064369Z qemu-system-x86_64: -machine accel=kvm:
unsupported machine type
On Sun, 20 Sep 2020 at 22:16, Paul Wouters wrote:
> On Sun, 20 Sep 2020, Andrew Cagney wrote:
>
> > - if orient() tries to load a cert and fails, should the connection be
> tossed or left unoriented?
>
> It's too late than isn't it? The connection is already loaded
On Mon, 21 Sep 2020 at 15:32, Antony Antony wrote:
> Andrew,
>
> after a closer look I see l2tp and ppp configuration file could be in the
> form 'hostname + "." + config_file' in the test directory.
>
> ikev1-l2tp-01/north.xl2tpd.conf
>
> they are not copied using the function that got fixed in
On Mon, 21 Sep 2020 at 13:53, Paul Wouters wrote:
> On Sun, 20 Sep 2020, Paul Wouters wrote:
>
> > Subject: [Swan-dev] nat: ikeport commit broke DDNS tests
>
> Fixed with commit 82ffa122d2500bb7a4
>
> That's probably a bandaid and not the best solution, but it can be
> cleaned up later when we
FYI, I removed the code because it seemed arbitrary. It would reject some,
but not all combinations of:
west.ipsec.secrets
westipsec.secrets
west.secrets
ipsec.secrets
I figured reducing this list to just:
west.ipsec.secrets
ipsec.secrets
(and perhaps only allowing one) +
On Fri, 18 Sep 2020 at 10:40, Andrew Cagney wrote:
>
>
> On Thu, 17 Sep 2020 at 16:05, Paul Wouters wrote:
>
>> On Thu, 17 Sep 2020, Andrew Cagney wrote:
>>
>> > Currently the code just warns when trying to add a connection with no
>> private key. In
I've removed the ones I think I fixed.
On Sat, 19 Sep 2020 at 18:10, wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to
> antonyantony/libreswan found with Coverity Scan.
>
> 13 new defect(s) introduced to antonyantony/libreswan found with Coverity
> Scan.
> 6
On Thu, 17 Sep 2020 at 16:05, Paul Wouters wrote:
> On Thu, 17 Sep 2020, Andrew Cagney wrote:
>
> > Currently the code just warns when trying to add a connection with no
> private key. Instead much much later - during the auth exchange - the
> > code tries to
On Thu, 17 Sep 2020 at 16:13, Paul Wouters wrote:
> On Wed, 16 Sep 2020, Andrew Cagney wrote:
>
> > First, I believe ikev2-03-basic-rawrsa-ckaid is fixed. It uses
> the CKAID to directly locate the raw key in the NSS DB. To confirm it is
> > working, look in west.pluto.lo
On Thu, 17 Sep 2020 at 12:42, Antony Antony wrote:
> On Wed, Sep 16, 2020 at 10:35:07PM -0400, Andrew Cagney wrote:
> > First, I believe ikev2-03-basic-rawrsa-ckaid is fixed. It uses
> the CKAID to
> > directly locate the raw key in the NSS DB. To confirm it
Currently the code just warns when trying to add a connection with no
private key. Instead much much later - during the auth exchange - the
code tries to find the private key.
Presumably this is because the end may not need the private key.
I'm wondering if there's enough information available
First, I believe ikev2-03-basic-rawrsa-ckaid is fixed. It uses
the CKAID to directly locate the raw key in the NSS DB. To confirm it is
working, look in west.pluto.log for "CKAID".
The use case for this test is pretty easy:
- generate the raw key
- use certutil to find the ckaid
- add ...ckaid=
p 2020, Andrew Cagney wrote:
>
> > There is {left,right}ikeport?
>
> Yes, but it does not seem to affect TCP :)
>
> Paul
>
> > On Tue, 15 Sep 2020 at 22:48, Paul Wouters wrote:
> >
> > Some changes were made a while ago to the TCP port handling. Y
There is {left,right}ikeport?
On Tue, 15 Sep 2020 at 22:48, Paul Wouters wrote:
>
> Some changes were made a while ago to the TCP port handling. You no
> longer specify a port in 'config setup'. Instead there is
> listen-tcp=yes|no and listen-udp=yes|no
>
> For UDP, you can set custom ikeport's
On Wed, 9 Sep 2020 at 10:06, Andrew Cagney wrote:
> I'm currently sweeping through the IKEv1 code (the assumption here is
> that, unlike IKEv2, IKEv1 is fair game) cleaning up anything found by:
>
> ./mk/find.sh \
> -e 'loglog(' \
> -e 'libreswan_log(' \
> -e
I'm currently sweeping through the IKEv1 code (the assumption here is that,
unlike IKEv2, IKEv1 is fair game) cleaning up anything found by:
./mk/find.sh \
-e 'loglog(' \
-e 'libreswan_log(' \
-e u_char \
-e 'FATAL_ERRNO(' \
-e 'LOG_ERRNO' \
-e '[^_]TRUE' \
-e
On Tue, 8 Sep 2020 at 11:25, Andrew Cagney wrote:
> So, I was going to post a thread to discuss these bugs; might as well
> hijack this one ...
>
> updated ikev2-03-basic-rawrsa-ckaid/description.txt:
>
> Querks when specifying the CKAID of a raw RSA key in a basic
crypt: encryption/decryption of messages: DANGER!
private: displays private information: DANGER!
I believe the idea behind private is that it dumps just enough information
for commands like tcpdump to decrypt packets (see ikev2_logParentSA()) and
perhaps recover DH material?
With that in
D to a connection so it mimics the ID code
below - be lazy.
This should fix the immediate problem of not finding east's pubkey. But
I'm sure we'll then hit another issue ...
> commit dffc14bdb3dd3f0b0dfb0cd4a64718b558f732bb
> Author: Andrew Cagney
> Date: Mon Sep 7 21:33:08 2020 -04
ntaining utter crap, yet had to be
marked as GOOD.
> -- Forwarded message --
> Date: Mon, 7 Sep 2020 17:29:35
> From: Andrew Cagney
> To: swan-com...@lists.libreswan.org
> Subject: [Swan-commit] Changes to ref refs/heads/main
>
> New commits:
> commit f22ca
On Mon, 7 Sep 2020 at 12:09, Paul Wouters wrote:
>
> On Sat, 5 Sep 2020, Andrew Cagney wrote:
>
> >> We removed the extra unused interfaces a few years ago that were in
> >> 192.1.9.0/24. Those were eth2 and could be used but never were. Except
> >> on
On Fri, 4 Sep 2020 at 22:40, Paul Wouters wrote:
>
> On Sep 4, 2020, at 15:59, Andrew Cagney wrote:
> >
> > I'd like to make the following changes to the domains:
> >
> > - make eth0 swandefault across all domains
> > this makes getting to the real
I'd like to make the following changes to the domains:
- make eth0 swandefault across all domains
this makes getting to the real domain and host much exier (OpenBSD
is already using swandefault when NFS mounting /testing)
- give all domains access to all internal networks, and with the same
On Thu, 3 Sep 2020 at 17:21, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | So why is that log file so big?
> |
> | Hmm ..., TCP. Hmm ...
> |
> | perhaps you need the custom kernel with the upstream tcp fixes?
>
> | > -rw-rw-r--. 1 build build
On Thu, 3 Sep 2020 at 13:24, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | there is a really really really big pluto.log somewhere?
>
> $ ls -s testing/pluto/*/OUTPUT/*pluto.log | sort -n | tail
> 1624
> testing/pluto/impair-08-ikev2-key-length-attribu
On Tue, 1 Sep 2020 at 11:34, D. Hugh Redelmeier wrote:
>
> Passing logger around is a very clean but noisy solution.
>
> But what is the problem?
>
> My impression is that the main problem is that using a global logger is
> hard to do correctly with threads.
No. The problem is the global
On Mon, 31 Aug 2020 at 23:47, D. Hugh Redelmeier wrote:
>
> After each run of the test suite, I use kvmresults.py to create a useful
> summary of how each test did.
>
> Recently it has crashed when I run it, but only after producing the
> results I want. So this isn't a big problem.
>
> Here's
On Tue, 1 Sep 2020 at 10:39, Paul Wouters wrote:
>
> On Mon, 31 Aug 2020, Andrew Cagney wrote:
>
> > I think I'll start by renaming the existing passert()/pexpect() to
> > PASSERT()/PEXPECT().
>
> That screams a lot...
Perhaps that will discourage its use :-) passer
On Fri, 21 Aug 2020 at 13:10, Andrew Cagney wrote:
>
> FYI,
> Currently if there's a pexpect() or passert() in a helper thread
> there's no context (state prefix) so it's not easy to proportion
> blame. Going forward (when cur_* are deleted) the main thread will
> hav
FYI,
Currently if there's a pexpect() or passert() in a helper thread
there's no context (state prefix) so it's not easy to proportion
blame. Going forward (when cur_* are deleted) the main thread will
have the same problem.
However, with loggers pretty much available everywhere, its possible
to
On Tue, 18 Aug 2020 at 22:24, Paul Wouters wrote:
>
> On Fri, 14 Aug 2020, Andrew Cagney wrote:
>
> > It was pointed out to me (offline) that swan-test contained a bashism
> > (== vs =), but on closer inspection it seems the file is dead so I
> > deleted it.
&
This finally follows up last years F2F. I've added a pre-receive hook
to reject foxtrot merges.
See https://blog.developer.atlassian.com/stop-foxtrots-now/
you'll get something like this:
[cagney@bernard wip-logging]$ git push
...
Total 7 (delta 5), reused 0 (delta 0), pack-reused 0
remote: ***
It was pointed out to me (offline) that swan-test contained a bashism
(== vs =), but on closer inspection it seems the file is dead so I
deleted it.
Are there more files and/or make targets that are a candidate for removal.
Off the top of my head there's the top-level 'make check' which, if it
is it the same thing?
On Thu, 13 Aug 2020 at 00:14, Paul Wouters wrote:
>
> On Wed, 12 Aug 2020, Andrew Cagney wrote:
>
> > there is also binlog
>
> I agree it needs to be replaced with https://varlink.org/
>
> I don't think we will get there for a 4.0 release though.
there is also binlog
On Wed, 12 Aug 2020 at 15:56, Paul Wouters wrote:
>
>
> I know I asked this before, but I just wanted to see if anyone changed
> their view on this since the last time. Should we keep or remove the
> nflog support in libreswan?
>
> Since we are doing a 4.0, now would be a
ote:
> > On Aug 10, 2020, at 21:19, Andrew Cagney wrote:
> > >
> > > I've been trimming the services installed/running from the KVM tests
> > > (zapping plymouth saved 30 minutes). I've so far cut things down to:
> > > https://libreswan.org/wiki/Test_Suite
201 - 300 of 1126 matches
Mail list logo
