Re: Harmonize examples in signify man page
I think it would be a mistake to change 'message.txt' etc (which are obviously filenames) to just 'message' which could be misinterpreted. I'm neutral on the other changes. -- Sent from a phone, apologies for poor formatting. On 24 February 2019 21:10:08 Matthias Schmidt wrote: Hi, while looking at signify's man page I noticed that the names of the arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc). The diff harmonizes the examples. It makes it easier to follow the examples. Cheers Matthias diff --git signify.1 signify.1 index de3b433e3b0..9f7335352a2 100644 --- signify.1 +++ signify.1 @@ -153,13 +153,13 @@ The message file is too large. .El .Sh EXAMPLES Create a new key pair: -.Dl $ signify -G -p newkey.pub -s newkey.sec +.Dl $ signify -G -p key.pub -s key.sec .Pp Sign a file, specifying a signature name: -.Dl $ signify -S -s key.sec -m message.txt -x msg.sig +.Dl $ signify -S -s key.sec -m message -x message.sig .Pp Verify a signature, using the default signature name: -.Dl $ signify -V -p key.pub -m generalsorders.txt +.Dl $ signify -V -p key.pub -m message .Pp Verify a release directory containing .Pa SHA256.sig @@ -175,7 +175,7 @@ $ signify -C -p /etc/signify/openbsd-65-base.pub -x SHA256.sig bsd.rd .Pp Sign a gzip archive: .Bd -literal -offset indent -compact -$ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz +$ signify -Sz -s key.sec -m in.tgz -x out.tgz .Ed .Pp Verify a gzip pipeline:
Re: ioctls for MPLS pseudowire interface config
On Mon, Feb 25, 2019 at 03:28:58PM +1000, David Gwynne wrote: > On Mon, Feb 25, 2019 at 10:37:40AM +1000, David Gwynne wrote: > > > > > > > On 22 Feb 2019, at 05:01, Martin Pieuchot wrote: > > > > > > On 21/02/19(Thu) 07:35, David Gwynne wrote: > > >>> On 20 Feb 2019, at 11:21 pm, Martin Pieuchot wrote: > > >>> > > >>> On 20/02/19(Wed) 14:44, David Gwynne wrote: > > Index: sys/net/if.c > > === > > RCS file: /cvs/src/sys/net/if.c,v > > retrieving revision 1.571 > > diff -u -p -r1.571 if.c > > --- sys/net/if.c 9 Jan 2019 01:14:21 - 1.571 > > +++ sys/net/if.c 20 Feb 2019 04:35:42 - > > @@ -2143,6 +2143,25 @@ ifioctl(struct socket *so, u_long cmd, c > > NET_UNLOCK(); > > break; > > > > + case SIOCSETMPWCFG: > > + case SIOCSPWE3CTRLWORD: > > + case SIOCSPWE3FAT: > > + case SIOCSPWE3NEIGHBOR: > > + case SIOCDPWE3NEIGHBOR: > > + if ((error = suser(p)) != 0) > > + break; > > + /* FALLTHROUGH */ > > + case SIOCGETMPWCFG: > > + case SIOCGPWE3CTRLWORD: > > + case SIOCGPWE3FAT: > > + case SIOCGPWE3NEIGHBOR: > > + if_ref(ifp); > > + KERNEL_UNLOCK(); > > + error = ((*ifp->if_ioctl)(ifp, cmd, data)); > > + KERNEL_LOCK(); > > + if_put(ifp); > > >>> > > >>> Why are you referencing the `ifp' and grabbing the KERNEL_LOCK() > > >>> (recursively)? > > >> > > >> ifioctl gets the ifp pointer from ifunit, which doesn't increase the ref > > >> count for you. I'm giving up kernel lock around the pwe3 ioctl calls > > >> into the driver, not taking them harder. Taking the ifp ref there > > >> guarantees the interface will stay alive^Wallocated over those calls. > > > > > > It feels premature to me, well I'm confused. None of the other ioctl > > > handlers do that. The KERNEL_LOCK() is still held in ifioctl() which > > > guarantees serialization. If any of the ioctl(2) calls is going to sleep, > > > thus releasing the lock, then I'd suggest to grab the NET_RLOCK() here > > > instead. It still guarantees serialization of network ioctls w/ regard > > > to detach. > > > > > > Note that I'll be delighted if you want to remove/push down the NET_LOCK() > > > from this code path, but can we keep the handlers coherent? > > > > > > Even if we're using refcounting, don't we want to serialize all network > > > ioctl(2)s? If we're not using the NET_LOCK() for this, can this new lock > > > guarantee that that `ifp' isn't going away? Or do you have a better > > > idea? > > > > The network stack implicitly taking locks is hurting me way more > > than it's helping me at the moment, particularly the net lock, so > > I would like to spend some time narrowing that down. If the consensus > > is that it's too much risk for drivers to keep themselves consistent > > then I'd argue for a per ifp rwlock that the ifioctl code could > > take and release. > > > > Do you want me to do that for the pwe3 ioctls? There's a small > > number of MPLS interfaces, so they'd be good for a test run. > > > > ifunit() is notionally like if_get except it doesn't give you a > > reference. You have to be holding a lock that prevents the interface > > being removed from the list if you're calling ifunit. The code > > doesn't make it clear whether the lock you need to be holding is > > the kernel lock or the net lock, but the kernel lock is empirically > > good enough. If you give up that lock while holding the ifp, you > > need to account for your reference to it. > > deraadt@ talked me down from giving up KERNEL_LOCK. so this is what > the diff would be like if the interface had a lock and it was taken > around the mpls ioctls. > > my opinion on the pros and cons of this is: > > pro: it keeps the individual driver state consistent cos changes > are serialised by the lock. this means you don't have to think too > hard about the driver locking against itself. > > pro: it allows fear free use of ifq_barrier. ifq_barrier cannot deadlock > if the caller isn't holding NET_LOCK. this is the big win because it > supports the model where the ioctl can coordinate with the running stack > by publishing a change and then inserting a barrier to ensure the old > state is no longer in use. without this the ioctl will have to give > up the implicit NET_LOCK it has. > > con: only the mpls/pwe3 ioctls are covered. but i have to start > somewhere, right? actually, now i have my head around the clone destroy stuff i can (ab)use the net lock. this should be more acceptable to everyone. Index: sys/sys/sockio.h === RCS file: /cvs/src/sys/sys/sockio.h,v retrieving revision 1.79 diff -u -p -r1.79 so
Re: ix(4): align rx payloads to the end of the cluster
On Mon, Feb 25, 2019 at 08:44:35AM +0100, Claudio Jeker wrote: > On Mon, Feb 25, 2019 at 10:49:16AM +1000, David Gwynne wrote: > > the mcl2k2 pool, aka the intel mbuf cluster pool, gets set up to allocate > > at least 2048 + 2 bytes, which gets rounded up by 64 bytes to 2112 > > bytes. this diff makes ix move the reception of packets to the end of > > the 2112 byte allocation so there's space left at the front of the mbuf. > > > > this in turn makes it more likely that an m_prepend at another point in > > the system will work without an extra mbuf allocation. eg, if you're > > bridging or routing between vlans and vlans on svlans somewhere else, > > this will be a bit faster with this diff. > > > > thoughts? ok? > > I think using m_align() here may be benefitial. Since it does exactly > that. Apart from that I have to agree, shifting the packet back makes a > lot of sense. Like this? Index: if_ix.c === RCS file: /cvs/src/sys/dev/pci/if_ix.c,v retrieving revision 1.153 diff -u -p -r1.153 if_ix.c --- if_ix.c 21 Feb 2019 03:16:47 - 1.153 +++ if_ix.c 25 Feb 2019 10:06:59 - @@ -2389,8 +2395,8 @@ ixgbe_get_buf(struct rx_ring *rxr, int i if (!mp) return (ENOBUFS); + m_align(mp, sc->rx_mbuf_sz); mp->m_len = mp->m_pkthdr.len = sc->rx_mbuf_sz; - m_adj(mp, ETHER_ALIGN); error = bus_dmamap_load_mbuf(rxr->rxdma.dma_tag, rxbuf->map, mp, BUS_DMA_NOWAIT);
Re: ix(4): align rx payloads to the end of the cluster
On Mon, Feb 25, 2019 at 08:08:32PM +1000, David Gwynne wrote: > On Mon, Feb 25, 2019 at 08:44:35AM +0100, Claudio Jeker wrote: > > On Mon, Feb 25, 2019 at 10:49:16AM +1000, David Gwynne wrote: > > > the mcl2k2 pool, aka the intel mbuf cluster pool, gets set up to allocate > > > at least 2048 + 2 bytes, which gets rounded up by 64 bytes to 2112 > > > bytes. this diff makes ix move the reception of packets to the end of > > > the 2112 byte allocation so there's space left at the front of the mbuf. > > > > > > this in turn makes it more likely that an m_prepend at another point in > > > the system will work without an extra mbuf allocation. eg, if you're > > > bridging or routing between vlans and vlans on svlans somewhere else, > > > this will be a bit faster with this diff. > > > > > > thoughts? ok? > > > > I think using m_align() here may be benefitial. Since it does exactly > > that. Apart from that I have to agree, shifting the packet back makes a > > lot of sense. > > Like this? OK claudio@ > Index: if_ix.c > === > RCS file: /cvs/src/sys/dev/pci/if_ix.c,v > retrieving revision 1.153 > diff -u -p -r1.153 if_ix.c > --- if_ix.c 21 Feb 2019 03:16:47 - 1.153 > +++ if_ix.c 25 Feb 2019 10:06:59 - > @@ -2389,8 +2395,8 @@ ixgbe_get_buf(struct rx_ring *rxr, int i > if (!mp) > return (ENOBUFS); > > + m_align(mp, sc->rx_mbuf_sz); > mp->m_len = mp->m_pkthdr.len = sc->rx_mbuf_sz; > - m_adj(mp, ETHER_ALIGN); > > error = bus_dmamap_load_mbuf(rxr->rxdma.dma_tag, rxbuf->map, > mp, BUS_DMA_NOWAIT); > -- :wq Claudio
Re: ld patch that greatly speeds up linking large programs with debug symbols
+cc sthen since ports/textproc/mupdf is affected by the bug:
http://build-failures.rhaalovely.net//sparc64/2019-02-03/textproc/mupdf.log
On Sun, Feb 24 2019, Jeremie Courreges-Anglas wrote:
> On Sat, Feb 23 2019, Aaron Miller wrote:
>> On February 23, 2019 2:50:46 AM PST, Jeremie Courreges-Anglas
>> wrote:
>>>On Sat, May 07 2016, Stefan Kempf wrote:
>
> [...]
>
>> Hi Jeremie,
>>
>> That is concerning. I'm on my phone and haven't had a chance to investigate,
>> but from the code in the gdb output above, it looks like the author of the
>> diff forgot to set the pointer to NULL after freeing. For example:
>> if (elf_tdata (sub)->symbuf) {
>> free (elf_tdata (sub)->symbuf);
>> elf_tdata (sub)->symbuf = NULL;
>> }
>>
>> This is not tested at all. I hope this works!
>
> It doesn't, which is consistent with the error seen with
> MALLOC_OPTIONS=S: "free (ptr=0xdbdbdbdbdbdbdbdb)" points out that the
> code uses uninitialized memory (0xdb). The 0xdf pattern in the sparc64
> build failure is likely newly allocated, uninitialized memory which
> had previously been junked by free(3).
The following diff fixes the issue here. The "bfd_get_flavour (sub) ==
bfd_target_elf_flavour" check is the important part, it mirrors the
checks done in bfd_elf_match_symbols_in_sections().
The "symbuf = NULL" part is not needed to avoid the crash, but if it can
avoid someone another dive in this codebase, I think it's worth it. ;)
Quick way to test the diff:
MALLOC_OPTIONS=S ld.bfd -r -b binary ~/.profile -o /tmp/garbage
ok?
Index: bfd/elflink.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elflink.c,v
retrieving revision 1.22
diff -u -p -r1.22 elflink.c
--- bfd/elflink.c 3 Dec 2018 02:59:51 - 1.22
+++ bfd/elflink.c 25 Feb 2019 09:49:05 -
@@ -8619,8 +8619,13 @@ bfd_elf_final_link (bfd *abfd, struct bf
if (!info->reduce_memory_overheads)
{
for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
- if (elf_tdata (sub)->symbuf)
- free (elf_tdata (sub)->symbuf);
+{
+ if (bfd_get_flavour (sub) == bfd_target_elf_flavour)
+{
+ free (elf_tdata (sub)->symbuf);
+ elf_tdata (sub)->symbuf = NULL;
+}
+}
}
/* Output any global symbols that got converted to local in a
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: start cleaning up UTF-8 processing in less(1)
> During the upcoming cleanup steps, let use retain full support for > the first (ESC-[) syntax and lets us completely delete support for > the second and third CSI syntaxes (single-byte CSI and UTF-8 > single-character two-byte CSI). > > If you are OK with that plan, i'll send diffs implementing that. Very little, if anything at all, uses 8-bit or UTF-8 CSI, getting rid of it is a good idea.
Re: ix(4): align rx payloads to the end of the cluster
> Date: Mon, 25 Feb 2019 08:44:35 +0100 > From: Claudio Jeker > > On Mon, Feb 25, 2019 at 10:49:16AM +1000, David Gwynne wrote: > > the mcl2k2 pool, aka the intel mbuf cluster pool, gets set up to allocate > > at least 2048 + 2 bytes, which gets rounded up by 64 bytes to 2112 > > bytes. this diff makes ix move the reception of packets to the end of > > the 2112 byte allocation so there's space left at the front of the mbuf. > > > > this in turn makes it more likely that an m_prepend at another point in > > the system will work without an extra mbuf allocation. eg, if you're > > bridging or routing between vlans and vlans on svlans somewhere else, > > this will be a bit faster with this diff. > > > > thoughts? ok? > > I think using m_align() here may be benefitial. Since it does exactly > that. Apart from that I have to agree, shifting the packet back makes a > lot of sense. As long as this still guarantees that packets are still aligned properly with the IP header on an 32-bit boundary... Should we add a KASSERT for that here? > > Index: dev/pci/if_ix.c > > === > > RCS file: /cvs/src/sys/dev/pci/if_ix.c,v > > retrieving revision 1.152 > > diff -u -p -r1.152 if_ix.c > > --- dev/pci/if_ix.c 22 Jun 2017 02:44:37 - 1.152 > > +++ dev/pci/if_ix.c 25 Feb 2019 00:40:47 - > > @@ -2445,7 +2445,7 @@ ixgbe_get_buf(struct rx_ring *rxr, int i > > return (ENOBUFS); > > > > mp->m_len = mp->m_pkthdr.len = sc->rx_mbuf_sz; > > - m_adj(mp, ETHER_ALIGN); > > + m_adj(mp, mp->m_ext.ext_size - sc->rx_mbuf_sz); > > > > error = bus_dmamap_load_mbuf(rxr->rxdma.dma_tag, rxbuf->map, > > mp, BUS_DMA_NOWAIT); > > > > -- > :wq Claudio > >
Re: ix(4): align rx payloads to the end of the cluster
On Mon, Feb 25, 2019 at 11:13:11AM +0100, Claudio Jeker wrote: > On Mon, Feb 25, 2019 at 08:08:32PM +1000, David Gwynne wrote: > > On Mon, Feb 25, 2019 at 08:44:35AM +0100, Claudio Jeker wrote: > > > On Mon, Feb 25, 2019 at 10:49:16AM +1000, David Gwynne wrote: > > > > the mcl2k2 pool, aka the intel mbuf cluster pool, gets set up to > > > > allocate > > > > at least 2048 + 2 bytes, which gets rounded up by 64 bytes to 2112 > > > > bytes. this diff makes ix move the reception of packets to the end of > > > > the 2112 byte allocation so there's space left at the front of the mbuf. > > > > > > > > this in turn makes it more likely that an m_prepend at another point in > > > > the system will work without an extra mbuf allocation. eg, if you're > > > > bridging or routing between vlans and vlans on svlans somewhere else, > > > > this will be a bit faster with this diff. > > > > > > > > thoughts? ok? > > > > > > I think using m_align() here may be benefitial. Since it does exactly > > > that. Apart from that I have to agree, shifting the packet back makes a > > > lot of sense. > > > > Like this? > > OK claudio@ Actually no, my bad. m_align() will align the buffer to a long word boundary and that's not what we want. But your first diff is also not quite right since m_len is modified by m_align and so the length is getting < 2048. (which may not matter here but better be 100% correct). Setting mp->m_len = mp->m_pkthdr.len = mp->m_ext.ext_size should do the trick. mp->m_len = mp->m_pkthdr.len = mp->m_ext.ext_size; m_adj(mp, mp->m_ext.ext_size - sc->rx_mbuf_sz; At least this should do what we want. > > Index: if_ix.c > > === > > RCS file: /cvs/src/sys/dev/pci/if_ix.c,v > > retrieving revision 1.153 > > diff -u -p -r1.153 if_ix.c > > --- if_ix.c 21 Feb 2019 03:16:47 - 1.153 > > +++ if_ix.c 25 Feb 2019 10:06:59 - > > @@ -2389,8 +2395,8 @@ ixgbe_get_buf(struct rx_ring *rxr, int i > > if (!mp) > > return (ENOBUFS); > > > > + m_align(mp, sc->rx_mbuf_sz); > > mp->m_len = mp->m_pkthdr.len = sc->rx_mbuf_sz; > > - m_adj(mp, ETHER_ALIGN); > > > > error = bus_dmamap_load_mbuf(rxr->rxdma.dma_tag, rxbuf->map, > > mp, BUS_DMA_NOWAIT); > > > > -- > :wq Claudio > -- :wq Claudio
Re: start cleaning up UTF-8 processing in less(1)
Hi,
Nicholas Marriott wrote on Mon, Feb 25, 2019 at 10:14:03AM +:
> Ingo Schwarze wrote:
>> During the upcoming cleanup steps, let use retain full support for
>> the first (ESC-[) syntax and lets us completely delete support for
>> the second and third CSI syntaxes (single-byte CSI and UTF-8
>> single-character two-byte CSI).
>>
>> If you are OK with that plan, i'll send diffs implementing that.
> Very little, if anything at all, uses 8-bit or UTF-8 CSI,
> getting rid of it is a good idea.
Thank you for all your feedback.
So here is a patch doing that.
The central part is dropping the definitions related to the 8-bit
and the UTF-8 CSI from less.h, keeping only the definitions needed
for ESC-[. In the future, these forms of the CSI will be treated
exactly like other control characters: e.g., encoded for display.
The rest of the diff mechanically resolves the IS_CSI_START() macro,
replacing it by a simple "== ESC" test. Casting is needed at none
of the places: the types involved are simply:
'[' int (value 0x5b < 0x7f)
037 int (value 0x1f < 0x7f) -- apply & -->
ESC int (value 0x1b < 0x7f)
So there is no danger in comparing ESC using == or != with any of
the types char, unsigned char (which are covered by the int range
during promotion) or LWCHAR == unsigned long, in which case the
(positve) constant ESC gets sign extended, which is value-preserving
for a positive integer.
The effects of the various chunks are, in detail:
* cvt.c, cvt_text():
8-bit and UTF-8 CSI are no longer recognized as ANSI escape
sequences but copied just like any other control characters.
* filename.c, bin_file():
8-bit and UTF-8 CSI are no longer skipped but counted as
binary characters just like any other binary characters.
(change in behaviour confirmed by testing)
* line.c, pshift():
No longer treat 8-bit and UTF-8 CSI sequences specially
when shifting a line left.
(shifting left and right was tested)
* line.c, in_ansi_esc_seq():
No longer recognize 8-bit and UTF-8 CSI sequences.
This allows simplifying the loop to iterate over bytes
rather than over characters, getting rif of one LWCHAR
variable and one call to the pesky function step_char(-1}.
(it was tested that ESC-[ still works)
* line.c, store_char():
No longer recognize 8-bit and UTF-8 CSI sequences.
Again, minus one LWCHAR and minus one step_char(-1).
* line.c, do_append():
No longer pass 8-bit and UTF-8 CSI unencoded, encode them
like any other control character.
This survived light testing.
All code touched will be touched again in the upcoming cleanup
because all these functions still contain step_char() or get_wchar(),
but this step simplifies many of the upcoming cleanup steps.
Already minus six lines of code and minus seven macro calls
in this patch alone.
OK?
Ingo
Index: cvt.c
===
RCS file: /cvs/src/usr.bin/less/cvt.c,v
retrieving revision 1.8
diff -u -p -r1.8 cvt.c
--- cvt.c 17 Sep 2016 15:06:41 - 1.8
+++ cvt.c 25 Feb 2019 11:25:38 -
@@ -77,7 +77,7 @@ cvt_text(char *odst, char *osrc, int *ch
dst--;
} while (dst > odst &&
!IS_ASCII_OCTET(*dst) && !IS_UTF8_LEAD(*dst));
- } else if ((ops & CVT_ANSI) && IS_CSI_START(ch)) {
+ } else if ((ops & CVT_ANSI) && ch == ESC) {
/* Skip to end of ANSI escape sequence. */
src++; /* skip the CSI start char */
while (src < src_end)
Index: filename.c
===
RCS file: /cvs/src/usr.bin/less/filename.c,v
retrieving revision 1.26
diff -u -p -r1.26 filename.c
--- filename.c 29 Oct 2017 17:10:55 - 1.26
+++ filename.c 25 Feb 2019 11:25:38 -
@@ -348,7 +348,7 @@ bin_file(int f)
pend = &data[n];
for (p = data; p < pend; ) {
LWCHAR c = step_char(&p, +1, pend);
- if (ctldisp == OPT_ONPLUS && IS_CSI_START(c)) {
+ if (ctldisp == OPT_ONPLUS && c == ESC) {
do {
c = step_char(&p, +1, pend);
} while (p < pend && is_ansi_middle(c));
Index: less.h
===
RCS file: /cvs/src/usr.bin/less/less.h,v
retrieving revision 1.28
diff -u -p -r1.28 less.h
--- less.h 30 Dec 2018 23:09:58 - 1.28
+++ less.h 25 Feb 2019 11:25:38 -
@@ -38,8 +38,6 @@
#defineIS_SPACE(c) isspace((unsigned char)(c))
#defineIS_DIGIT(c) isdigit((unsigned char)(c))
-#defineIS_CSI_START(c) (((LWCHAR)(c)) == ESC || (((LWCHAR)(c)) == CSI))
-
#ifndef TRUE
#defineTRUE1
#endif
@@ -151,9 +149,7 @@ struct textlist {
#defineAT_INDET(1 << 7)
Re: remove date from signify zsig
Hi,
I, too, would like to have a way of signing the gzip archive in a
reproducible way, so here's a diff that uses -n, similar to gzip(1).
However, if that's a bad idea, I'm fine with continuing to use an
unsigned gzip archive and creating a sigfile with signify.
Regards
Andre
Index: signify.1
===
RCS file: /cvs/src/usr.bin/signify/signify.1,v
retrieving revision 1.44
diff -u -p -r1.44 signify.1
--- signify.1 10 Aug 2018 20:27:01 - 1.44
+++ signify.1 25 Feb 2019 11:55:57 -
@@ -35,7 +35,7 @@
.Fl s Ar seckey
.Nm signify
.Fl S
-.Op Fl ez
+.Op Fl enz
.Op Fl x Ar sigfile
.Fl s Ar seckey
.Fl m Ar message
@@ -91,10 +91,15 @@ When verifying with
.Fl e ,
the file to create.
.It Fl n
-Do not ask for a passphrase during key generation.
+When generating a key pair, do not ask for a passphrase.
Otherwise,
.Nm
will prompt the user for a passphrase to protect the secret key.
+When signing with
+.Fl z ,
+do not store the time stamp in the
+.Xr gzip 1
+header.
.It Fl p Ar pubkey
Public key produced by
.Fl G ,
Index: signify.c
===
RCS file: /cvs/src/usr.bin/signify/signify.c,v
retrieving revision 1.130
diff -u -p -r1.130 signify.c
--- signify.c 17 Jan 2019 05:40:10 - 1.130
+++ signify.c 25 Feb 2019 11:55:57 -
@@ -80,7 +80,7 @@ usage(const char *error)
#ifndef VERIFYONLY
"\t%1$s -C [-q] -p pubkey -x sigfile [file ...]\n"
"\t%1$s -G [-n] [-c comment] -p pubkey -s seckey\n"
- "\t%1$s -S [-ez] [-x sigfile] -s seckey -m message\n"
+ "\t%1$s -S [-enz] [-x sigfile] -s seckey -m message\n"
#endif
"\t%1$s -V [-eqz] [-p pubkey] [-t keytype] [-x sigfile] -m
message\n",
getprogname());
@@ -878,7 +878,7 @@ main(int argc, char **argv)
if (gzip) {
if (!msgfile || !seckeyfile || !sigfile)
usage("must specify message sigfile seckey");
- zsign(seckeyfile, msgfile, sigfile);
+ zsign(seckeyfile, msgfile, sigfile, rounds);
} else {
if (!msgfile || !seckeyfile)
usage("must specify message and seckey");
Index: signify.h
===
RCS file: /cvs/src/usr.bin/signify/signify.h,v
retrieving revision 1.1
diff -u -p -r1.1 signify.h
--- signify.h 2 Sep 2016 16:10:56 - 1.1
+++ signify.h 25 Feb 2019 11:55:57 -
@@ -19,7 +19,7 @@
#ifndef signify_h
#define signify_h
extern void zverify(const char *, const char *, const char *, const char *);
-extern void zsign(const char *, const char *, const char *);
+extern void zsign(const char *, const char *, const char *, int);
extern void *xmalloc(size_t);
extern void writeall(int, const void *, size_t, const char *);
Index: zsig.c
===
RCS file: /cvs/src/usr.bin/signify/zsig.c,v
retrieving revision 1.15
diff -u -p -r1.15 zsig.c
--- zsig.c 11 Jul 2017 23:52:05 - 1.15
+++ zsig.c 25 Feb 2019 11:55:57 -
@@ -231,7 +231,8 @@ zverify(const char *pubkeyfile, const ch
}
void
-zsign(const char *seckeyfile, const char *msgfile, const char *sigfile)
+zsign(const char *seckeyfile, const char *msgfile, const char *sigfile,
+int storedate)
{
size_t bufsize = MYBUFSIZE;
int fdin, fdout;
@@ -242,8 +243,6 @@ zsign(const char *seckeyfile, const char
char *p;
uint8_t *buffer;
uint8_t *sighdr;
- char date[80];
- time_t clock;
fdin = xopen(msgfile, O_RDONLY, 0);
if (fstat(fdin, &sb) == -1 || !S_ISREG(sb.st_mode))
@@ -261,14 +260,24 @@ zsign(const char *seckeyfile, const char
msg = xmalloc(space);
buffer = xmalloc(bufsize);
- time(&clock);
- strftime(date, sizeof date, "%Y-%m-%dT%H:%M:%SZ", gmtime(&clock));
- snprintf(msg, space,
- "date=%s\n"
- "key=%s\n"
- "algorithm=SHA512/256\n"
- "blocksize=%zu\n\n",
- date, seckeyfile, bufsize);
+ if (storedate) {
+ char date[80];
+ time_t clock;
+ time(&clock);
+ strftime(date, sizeof date, "%Y-%m-%dT%H:%M:%SZ",
+ gmtime(&clock));
+ snprintf(msg, space,
+ "date=%s\n"
+ "key=%s\n"
+ "algorithm=SHA512/256\n"
+ "blocksize=%zu\n\n",
+ date, seckeyfile, bufsize);
+ } else
+ snprintf(msg, space,
+ "key=%s\n"
+ "algorithm=SHA512/256\n"
+ "blocksize=%zu\n\n",
+ seckeyfile, bufsize);
p = strchr(msg, 0);
while (1) {
patch axen(4) (WIP)
Hi,
as mentioned previously, I'm looking into axen(4). While searching
for the cause of a panic (fixed since, thanks mpi@) I started to
rewrite parts of the driver. References were mainly the FreeBSD and
Linux drivers.
I didn't get around to much testing/debugging lately, therefore I
wanted to share the current state (diff below).
The current state works a lot better than previously (for me). I
used to have a huge amount of ierrs (aprrox. 1 ierr per ipkt) and
often no packets would be transferred at all (or stop being transferred
after some time).
This box hosts backups (rsync and TimeMachine), so it gets its fair
share of traffic. I could reduce the ierrs to ~2100 with 5d uptime,
and the packets keep flowing:
$ netstat -niI axen0
NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls
axen0 150094:c6:91:1f:85:a5 141199356 2099 112289969 0 0
$ uptime
7:15PM up 5 days, 9:57, 3 users, load averages: 0.11, 0.13, 0.14
$
But there a still a few problems:
1) There are still ierrs. These happen when the rx path can't
allocate mbufs (cf. diff below for DPRINTF):
axen0: could not allocate rx mbuf (2 total, 2 remaining)
axen0: could not allocate rx mbuf (3 total, 3 remaining)
axen0: could not allocate rx mbuf (2 total, 2 remaining)
axen0: could not allocate rx mbuf (1 total, 1 remaining)
2) If the adapter is plugged into a USB 3 port at boot, it will
return 0x42 when aked for AXEN_PHYSICAL_LINK_STATUS, ie.
(AXEN_EPHY_1000|AXEN_USB_HS). The adapter most often then simply
doesn't receive packets. If I plug in the adapter after boot is
complete, 0x44 is returned (AXEN_EPHY_1000|AXEN_USB_SS), as expected.
I'm not sure if I'm still missing something in init (probably) or
if this results from something higher in the stack (xhci?).
(Didn't test USB 2 or lower.)
3) Transfer speed
Here's the diff:
Index: dev/usb/if_axen.c
===
RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
retrieving revision 1.26
diff -u -p -r1.26 if_axen.c
--- dev/usb/if_axen.c 5 Dec 2018 15:54:58 - 1.26
+++ dev/usb/if_axen.c 12 Feb 2019 18:26:48 -
@@ -97,7 +97,7 @@ const struct cfattach axen_ca = {
intaxen_tx_list_init(struct axen_softc *);
intaxen_rx_list_init(struct axen_softc *);
-struct mbuf *axen_newbuf(void);
+struct mbuf *axen_newbuf(struct axen_softc *);
intaxen_encap(struct axen_softc *, struct mbuf *, int);
void axen_rxeof(struct usbd_xfer *, void *, usbd_status);
void axen_txeof(struct usbd_xfer *, void *, usbd_status);
@@ -121,6 +121,13 @@ void axen_unlock_mii(struct axen_softc *
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, AXEN_BUFSZ_SS, 0xff },
+ { 7, 0x20, 0x03, AXEN_BUFSZ_HS, 0xff },
+ { 7, 0xae, 0x07, AXEN_BUFSZ_LS, 0xff },
+ { 7, 0xcc, 0x4c, AXEN_BUFSZ_LS, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -156,7 +163,7 @@ axen_cmd(struct axen_softc *sc, int cmd,
USETW(req.wLength, AXEN_CMD_LEN(cmd));
err = usbd_do_request(sc->axen_udev, &req, buf);
- DPRINTFN(5, ("axen_cmd: cmd 0x%04x val 0x%04x len %d\n",
+ DPRINTFN(15, ("axen_cmd: cmd 0x%04x val 0x%04x len %d\n",
cmd, val, AXEN_CMD_LEN(cmd)));
if (err) {
@@ -193,7 +200,7 @@ axen_miibus_readreg(struct device *dev,
}
ival = UGETW(val);
- DPRINTFN(2,("axen_miibus_readreg: phy 0x%x reg 0x%x val 0x%x\n",
+ DPRINTFN(12,("axen_miibus_readreg: phy 0x%x reg 0x%x val 0x%x\n",
phy, reg, ival));
if (reg == MII_BMSR) {
@@ -220,7 +227,7 @@ axen_miibus_writereg(struct device *dev,
axen_lock_mii(sc);
err = axen_cmd(sc, AXEN_CMD_MII_WRITE_REG, reg, phy, &uval);
axen_unlock_mii(sc);
- DPRINTFN(2, ("axen_miibus_writereg: phy 0x%x reg 0x%x val 0x%0x\n",
+ DPRINTFN(12, ("axen_miibus_writereg: phy 0x%x reg 0x%x val 0x%0x\n",
phy, reg, val));
if (err) {
@@ -236,13 +243,17 @@ axen_miibus_statchg(struct device *dev)
struct mii_data *mii = GET_MII(sc);
struct ifnet*ifp;
int err;
+ uint8_t link_status;
uint16_tval;
uWord wval;
+ struct axen_qctrl *qctrl;
+
+ axen_lock_mii(sc);
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
(ifp->if_flags & IFF_RUNNING) == 0)
- return;
+ goto done;
sc->axen_link = 0;
if ((mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) ==
@@ -250,10 +261,8 @@ axen_miibus_statchg(struct device *dev)
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_10_T:
case IFM_100_TX:
- sc->axen_link++;
- b
Re: start cleaning up UTF-8 processing in less(1)
On Mon, 25 Feb 2019 12:39:41 +0100, Ingo Schwarze wrote:
One question inline.
- todd
> Index: line.c
> ===
> RCS file: /cvs/src/usr.bin/less/line.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 line.c
> --- line.c24 Feb 2019 04:54:36 - 1.23
> +++ line.c25 Feb 2019 11:25:39 -
> @@ -230,7 +230,7 @@ pshift(int shift)
>*/
> while (shifted <= shift && from < curr) {
> c = linebuf[from];
> - if (ctldisp == OPT_ONPLUS && IS_CSI_START(c)) {
> + if (ctldisp == OPT_ONPLUS && c == ESC) {
> /* Keep cumulative effect. */
> linebuf[to] = c;
> attr[to++] = attr[from++];
> @@ -469,11 +469,10 @@ in_ansi_esc_seq(void)
>* Search backwards for either an ESC (which means we ARE in a seq);
>* or an end char (which means we're NOT in a seq).
>*/
> - for (p = &linebuf[curr]; p > linebuf; ) {
> - LWCHAR ch = step_char(&p, -1, linebuf);
> - if (IS_CSI_START(ch))
> + for (p = linebuf + curr - 1; p >= linebuf; p--) {
Since curr can be 0, can this lead to be a single byte underflow?
> + if (*p == ESC)
> return (1);
> - if (!is_ansi_middle(ch))
> + if (!is_ansi_middle(*p))
> return (0);
> }
> return (0);
> @@ -533,17 +532,14 @@ store_char(LWCHAR ch, char a, char *rep,
> if (ctldisp == OPT_ONPLUS && in_ansi_esc_seq()) {
> if (!is_ansi_end(ch) && !is_ansi_middle(ch)) {
> /* Remove whole unrecognized sequence. */
> - char *p = &linebuf[curr];
> - LWCHAR bch;
> do {
> - bch = step_char(&p, -1, linebuf);
> - } while (p > linebuf && !IS_CSI_START(bch));
> - curr = p - linebuf;
> + curr--;
> + } while (curr > 0 && linebuf[curr] != ESC);
> return (0);
> }
> a = AT_ANSI;/* Will force re-AT_'ing around it. */
> w = 0;
> - } else if (ctldisp == OPT_ONPLUS && IS_CSI_START(ch)) {
> + } else if (ctldisp == OPT_ONPLUS && ch == ESC) {
> a = AT_ANSI;/* Will force re-AT_'ing around it. */
> w = 0;
> } else {
> @@ -851,7 +847,7 @@ do_append(LWCHAR ch, char *rep, off_t po
> } else if ((!utf_mode || is_ascii_char(ch)) && control_char((char)ch))
> {
> do_control_char:
> if (ctldisp == OPT_ON ||
> - (ctldisp == OPT_ONPLUS && IS_CSI_START(ch))) {
> + (ctldisp == OPT_ONPLUS && ch == ESC)) {
> /*
>* Output as a normal character.
>*/
Re: start cleaning up UTF-8 processing in less(1)
Hi Todd,
Todd C. Miller wrote on Mon, Feb 25, 2019 at 09:45:12AM -0700:
> One question inline.
> On Mon, 25 Feb 2019 12:39:41 +0100, Ingo Schwarze wrote:
>> Index: line.c
[...]
>> @@ -469,11 +469,10 @@ in_ansi_esc_seq(void)
>> * Search backwards for either an ESC (which means we ARE in a seq);
>> * or an end char (which means we're NOT in a seq).
>> */
>> -for (p = &linebuf[curr]; p > linebuf; ) {
>> -LWCHAR ch = step_char(&p, -1, linebuf);
>> -if (IS_CSI_START(ch))
>> +for (p = linebuf + curr - 1; p >= linebuf; p--) {
> Since curr can be 0, can this lead to be a single byte underflow?
No, in that case (which logically means the line buffer is empty),
the end condition p >= linebuf is false right away, the loop
is never entered, the function returns 0 right away and at the
call site, the first if brach (containing "curr--") isn't entered
either.
Yours,
Ingo
Re: patch axen(4) (WIP)
On 25/02/19(Mon) 14:52, Nils Frohberg wrote:
> Hi,
>
> as mentioned previously, I'm looking into axen(4). While searching
> for the cause of a panic (fixed since, thanks mpi@) I started to
> rewrite parts of the driver. References were mainly the FreeBSD and
> Linux drivers.
Please try to isolate parts of your diff that fixes issues and cosmetic
changes. The simpler it gets the easier it is for us to review it.
> I didn't get around to much testing/debugging lately, therefore I
> wanted to share the current state (diff below).
>
> The current state works a lot better than previously (for me). I
> used to have a huge amount of ierrs (aprrox. 1 ierr per ipkt) and
> often no packets would be transferred at all (or stop being transferred
> after some time).
Do you know why? What were the problems?
> This box hosts backups (rsync and TimeMachine), so it gets its fair
> share of traffic. I could reduce the ierrs to ~2100 with 5d uptime,
> and the packets keep flowing:
>
> $ netstat -niI axen0
> NameMtu Network Address Ipkts IerrsOpkts Oerrs
> Colls
> axen0 150094:c6:91:1f:85:a5 141199356 2099 112289969 0
> 0
> $ uptime
> 7:15PM up 5 days, 9:57, 3 users, load averages: 0.11, 0.13, 0.14
> $
>
> But there a still a few problems:
>
> 1) There are still ierrs. These happen when the rx path can't
> allocate mbufs (cf. diff below for DPRINTF):
> axen0: could not allocate rx mbuf (2 total, 2 remaining)
> axen0: could not allocate rx mbuf (3 total, 3 remaining)
> axen0: could not allocate rx mbuf (2 total, 2 remaining)
> axen0: could not allocate rx mbuf (1 total, 1 remaining)
Look at the pools when this happen, what do you see? What is the size
of `pkt_len' when this happen?
> 2) If the adapter is plugged into a USB 3 port at boot, it will
> return 0x42 when aked for AXEN_PHYSICAL_LINK_STATUS, ie.
> (AXEN_EPHY_1000|AXEN_USB_HS). The adapter most often then simply
> doesn't receive packets. If I plug in the adapter after boot is
> complete, 0x44 is returned (AXEN_EPHY_1000|AXEN_USB_SS), as expected.
> I'm not sure if I'm still missing something in init (probably) or
> if this results from something higher in the stack (xhci?).
> (Didn't test USB 2 or lower.)
Do you see any difference in 'usbdevs -vv' output during the two cases?
>
> 3) Transfer speed
>
> Here's the diff:
>
> Index: dev/usb/if_axen.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 if_axen.c
> --- dev/usb/if_axen.c 5 Dec 2018 15:54:58 - 1.26
> +++ dev/usb/if_axen.c 12 Feb 2019 18:26:48 -
> @@ -97,7 +97,7 @@ const struct cfattach axen_ca = {
>
> int axen_tx_list_init(struct axen_softc *);
> int axen_rx_list_init(struct axen_softc *);
> -struct mbuf *axen_newbuf(void);
> +struct mbuf *axen_newbuf(struct axen_softc *);
> int axen_encap(struct axen_softc *, struct mbuf *, int);
> void axen_rxeof(struct usbd_xfer *, void *, usbd_status);
> void axen_txeof(struct usbd_xfer *, void *, usbd_status);
> @@ -121,6 +121,13 @@ void axen_unlock_mii(struct axen_softc *
>
> void axen_ax88179_init(struct axen_softc *);
>
> +struct axen_qctrl axen_bulk_size[] = {
> + { 7, 0x4f, 0x00, AXEN_BUFSZ_SS, 0xff },
> + { 7, 0x20, 0x03, AXEN_BUFSZ_HS, 0xff },
> + { 7, 0xae, 0x07, AXEN_BUFSZ_LS, 0xff },
> + { 7, 0xcc, 0x4c, AXEN_BUFSZ_LS, 0x08 }
> +};
> +
> /* Get exclusive access to the MII registers */
> void
> axen_lock_mii(struct axen_softc *sc)
> @@ -156,7 +163,7 @@ axen_cmd(struct axen_softc *sc, int cmd,
> USETW(req.wLength, AXEN_CMD_LEN(cmd));
>
> err = usbd_do_request(sc->axen_udev, &req, buf);
> - DPRINTFN(5, ("axen_cmd: cmd 0x%04x val 0x%04x len %d\n",
> + DPRINTFN(15, ("axen_cmd: cmd 0x%04x val 0x%04x len %d\n",
> cmd, val, AXEN_CMD_LEN(cmd)));
>
> if (err) {
> @@ -193,7 +200,7 @@ axen_miibus_readreg(struct device *dev,
> }
>
> ival = UGETW(val);
> - DPRINTFN(2,("axen_miibus_readreg: phy 0x%x reg 0x%x val 0x%x\n",
> + DPRINTFN(12,("axen_miibus_readreg: phy 0x%x reg 0x%x val 0x%x\n",
> phy, reg, ival));
>
> if (reg == MII_BMSR) {
> @@ -220,7 +227,7 @@ axen_miibus_writereg(struct device *dev,
> axen_lock_mii(sc);
> err = axen_cmd(sc, AXEN_CMD_MII_WRITE_REG, reg, phy, &uval);
> axen_unlock_mii(sc);
> - DPRINTFN(2, ("axen_miibus_writereg: phy 0x%x reg 0x%x val 0x%0x\n",
> + DPRINTFN(12, ("axen_miibus_writereg: phy 0x%x reg 0x%x val 0x%0x\n",
> phy, reg, val));
>
> if (err) {
> @@ -236,13 +243,17 @@ axen_miibus_statchg(struct device *dev)
> struct mii_data *mii = GET_MII(sc);
> struct ifnet*ifp;
> int err;
> + uint8_t link_status;
> uint16_tval;
> uWord wval;
> + struct axen_qctrl *qctrl;
>
Re: remove date from signify zsig
Andre Stoebe wrote: > Hi, > > I, too, would like to have a way of signing the gzip archive in a > reproducible way, so here's a diff that uses -n, similar to gzip(1). > > However, if that's a bad idea, I'm fine with continuing to use an > unsigned gzip archive and creating a sigfile with signify. Let me think on this for a bit. Seems reasonable, though.
Re: start cleaning up UTF-8 processing in less(1)
On Mon, 25 Feb 2019 19:43:36 +0100, Ingo Schwarze wrote:
> Todd C. Miller wrote on Mon, Feb 25, 2019 at 09:45:12AM -0700:
>
> > On Mon, 25 Feb 2019 12:39:41 +0100, Ingo Schwarze wrote:
>
> >> Index: line.c
> [...]
> >> @@ -469,11 +469,10 @@ in_ansi_esc_seq(void)
> >> * Search backwards for either an ESC (which means we ARE in a seq);
> >> * or an end char (which means we're NOT in a seq).
> >> */
> >> - for (p = &linebuf[curr]; p > linebuf; ) {
> >> - LWCHAR ch = step_char(&p, -1, linebuf);
> >> - if (IS_CSI_START(ch))
> >> + for (p = linebuf + curr - 1; p >= linebuf; p--) {
>
> > Since curr can be 0, can this lead to be a single byte underflow?
>
> No, in that case (which logically means the line buffer is empty),
> the end condition p >= linebuf is false right away, the loop
> is never entered, the function returns 0 right away and at the
> call site, the first if brach (containing "curr--") isn't entered
> either.
Strictly speaking, the result of "p = linebuf + curr - 1" is undefined
when curr < 1. There is a special case in the standard when the
result is one past the end of an array but no corresponding case
for one element before the array. In practice, it is unlikely to
matter.
- todd
Re: Harmonize examples in signify man page
Matthias Schmidt wrote: > Hi, > > while looking at signify's man page I noticed that the names of the > arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc). > The diff harmonizes the examples. It makes it easier to follow the examples. I don't think the intention was to present a complete workflow. They're kinda standalone. That said, the gzip ones *do* depend on each other, and the change below would break the verification in the later example. To be honest, the first three examples are probably too simple to be interesting, but they're short enough they don't take up much space. The next two examples are useful recipes. And the gzip mode is different enough some examples are useful. > Sign a gzip archive: > .Bd -literal -offset indent -compact > -$ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz > +$ signify -Sz -s key.sec -m in.tgz -x out.tgz > .Ed > .Pp > Verify a gzip pipeline:
Re: remove date from signify zsig
On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote: > Andre Stoebe wrote: > > Hi, > > > > I, too, would like to have a way of signing the gzip archive in a > > reproducible way, so here's a diff that uses -n, similar to gzip(1). > > > > However, if that's a bad idea, I'm fine with continuing to use an > > unsigned gzip archive and creating a sigfile with signify. > > Let me think on this for a bit. Seems reasonable, though. If you want something simpler, just set the date from outside through an env variable, so you'll have a reproducible date line for when you absolutely need it.
Re: Harmonize examples in signify man page
On Sun, Feb 24, 2019 at 10:09:43PM +0100, Matthias Schmidt wrote: > Hi, > > while looking at signify's man page I noticed that the names of the > arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc). > The diff harmonizes the examples. It makes it easier to follow the examples. > > Cheers > > Matthias > > diff --git signify.1 signify.1 > index de3b433e3b0..9f7335352a2 100644 > --- signify.1 > +++ signify.1 > @@ -153,13 +153,13 @@ The message file is too large. > .El > .Sh EXAMPLES > Create a new key pair: > -.Dl $ signify -G -p newkey.pub -s newkey.sec > +.Dl $ signify -G -p key.pub -s key.sec > .Pp > Sign a file, specifying a signature name: > -.Dl $ signify -S -s key.sec -m message.txt -x msg.sig > +.Dl $ signify -S -s key.sec -m message -x message.sig Your mileage may vary, but this makes things harder to follow for me. Obviously visually differentiating between creating new keys and using existing ones makes a lot of sense for me. Especially since the examples are not meant to be chained together, at all. This is a reference manual, not a tutorial.
Re: remove date from signify zsig
Marc Espie wrote: > On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote: > > Andre Stoebe wrote: > > > Hi, > > > > > > I, too, would like to have a way of signing the gzip archive in a > > > reproducible way, so here's a diff that uses -n, similar to gzip(1). > > > > > > However, if that's a bad idea, I'm fine with continuing to use an > > > unsigned gzip archive and creating a sigfile with signify. > > > > Let me think on this for a bit. Seems reasonable, though. > > If you want something simpler, just set the date from outside through an > env variable, so you'll have a reproducible date line for when you absolutely > need it. Like TZ? I don't think there's a way to change the time that way. Is there?
Re: remove date from signify zsig
On Mon, Feb 25, 2019 at 05:11:54PM -0500, Ted Unangst wrote: > Marc Espie wrote: > > On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote: > > > Andre Stoebe wrote: > > > > Hi, > > > > > > > > I, too, would like to have a way of signing the gzip archive in a > > > > reproducible way, so here's a diff that uses -n, similar to gzip(1). > > > > > > > > However, if that's a bad idea, I'm fine with continuing to use an > > > > unsigned gzip archive and creating a sigfile with signify. > > > > > > Let me think on this for a bit. Seems reasonable, though. > > > > If you want something simpler, just set the date from outside through an > > env variable, so you'll have a reproducible date line for when you > > absolutely > > need it. > > Like TZ? I don't think there's a way to change the time that way. Is there? No, but instead of an extra option, a specific env variable ? might make more sense... or less. I don't know. I'm surprised this surfaced again, as the subject was broached a few months ago and dismissed, because yep, we do want the timestamp to mean something for pkg_add. Especially relating to our keys having a shelf life.
Re: start cleaning up UTF-8 processing in less(1)
Hi Todd,
Todd C. Miller wrote on Mon, Feb 25, 2019 at 01:06:02PM -0700:
> On Mon, 25 Feb 2019 19:43:36 +0100, Ingo Schwarze wrote:
>> Todd C. Miller wrote on Mon, Feb 25, 2019 at 09:45:12AM -0700:
>>> On Mon, 25 Feb 2019 12:39:41 +0100, Ingo Schwarze wrote:
Index: line.c
>> [...]
@@ -469,11 +469,10 @@ in_ansi_esc_seq(void)
* Search backwards for either an ESC (which means we ARE in a seq);
* or an end char (which means we're NOT in a seq).
*/
- for (p = &linebuf[curr]; p > linebuf; ) {
- LWCHAR ch = step_char(&p, -1, linebuf);
- if (IS_CSI_START(ch))
+ for (p = linebuf + curr - 1; p >= linebuf; p--) {
>>> Since curr can be 0, can this lead to be a single byte underflow?
>> No, in that case (which logically means the line buffer is empty),
>> the end condition p >= linebuf is false right away, the loop
>> is never entered, the function returns 0 right away and at the
>> call site, the first if brach (containing "curr--") isn't entered
>> either.
> Strictly speaking, the result of "p = linebuf + curr - 1" is undefined
> when curr < 1. There is a special case in the standard when the
> result is one past the end of an array but no corresponding case
> for one element before the array. In practice, it is unlikely to
> matter.
Ouch, i keep forgetting that one, thanks for reminding me.
In that case, let's just use an index rather than a pointer;
diff otherwise unchanged.
OK?
Ingo
Index: cvt.c
===
RCS file: /cvs/src/usr.bin/less/cvt.c,v
retrieving revision 1.8
diff -u -p -r1.8 cvt.c
--- cvt.c 17 Sep 2016 15:06:41 - 1.8
+++ cvt.c 26 Feb 2019 01:31:31 -
@@ -77,7 +77,7 @@ cvt_text(char *odst, char *osrc, int *ch
dst--;
} while (dst > odst &&
!IS_ASCII_OCTET(*dst) && !IS_UTF8_LEAD(*dst));
- } else if ((ops & CVT_ANSI) && IS_CSI_START(ch)) {
+ } else if ((ops & CVT_ANSI) && ch == ESC) {
/* Skip to end of ANSI escape sequence. */
src++; /* skip the CSI start char */
while (src < src_end)
Index: filename.c
===
RCS file: /cvs/src/usr.bin/less/filename.c,v
retrieving revision 1.26
diff -u -p -r1.26 filename.c
--- filename.c 29 Oct 2017 17:10:55 - 1.26
+++ filename.c 26 Feb 2019 01:31:31 -
@@ -348,7 +348,7 @@ bin_file(int f)
pend = &data[n];
for (p = data; p < pend; ) {
LWCHAR c = step_char(&p, +1, pend);
- if (ctldisp == OPT_ONPLUS && IS_CSI_START(c)) {
+ if (ctldisp == OPT_ONPLUS && c == ESC) {
do {
c = step_char(&p, +1, pend);
} while (p < pend && is_ansi_middle(c));
Index: less.h
===
RCS file: /cvs/src/usr.bin/less/less.h,v
retrieving revision 1.28
diff -u -p -r1.28 less.h
--- less.h 30 Dec 2018 23:09:58 - 1.28
+++ less.h 26 Feb 2019 01:31:31 -
@@ -38,8 +38,6 @@
#defineIS_SPACE(c) isspace((unsigned char)(c))
#defineIS_DIGIT(c) isdigit((unsigned char)(c))
-#defineIS_CSI_START(c) (((LWCHAR)(c)) == ESC || (((LWCHAR)(c)) == CSI))
-
#ifndef TRUE
#defineTRUE1
#endif
@@ -151,9 +149,7 @@ struct textlist {
#defineAT_INDET(1 << 7) /* Indeterminate: either bold or
underline */
#defineCONTROL(c) ((c)&037)
-
#defineESC CONTROL('[')
-#defineCSI ((unsigned char)'\233')
#defineS_INTERRUPT 01
#defineS_STOP 02
Index: line.c
===
RCS file: /cvs/src/usr.bin/less/line.c,v
retrieving revision 1.23
diff -u -p -r1.23 line.c
--- line.c 24 Feb 2019 04:54:36 - 1.23
+++ line.c 26 Feb 2019 01:31:31 -
@@ -230,7 +230,7 @@ pshift(int shift)
*/
while (shifted <= shift && from < curr) {
c = linebuf[from];
- if (ctldisp == OPT_ONPLUS && IS_CSI_START(c)) {
+ if (ctldisp == OPT_ONPLUS && c == ESC) {
/* Keep cumulative effect. */
linebuf[to] = c;
attr[to++] = attr[from++];
@@ -463,17 +463,16 @@ backc(void)
static int
in_ansi_esc_seq(void)
{
- char *p;
+ int i;
/*
* Search backwards for either an ESC (which means we ARE in a seq);
* or an end char (which means we're NOT in a seq).
*/
- for (p = &linebuf[curr]; p > linebuf; ) {
- LWCHAR ch = step_char(&p, -1, linebuf);
- if (IS_CSI_START(ch))
+ for (i = curr - 1; i >= 0; i--) {
+
Re: start cleaning up UTF-8 processing in less(1)
On Tue, 26 Feb 2019 02:39:14 +0100, Ingo Schwarze wrote: > In that case, let's just use an index rather than a pointer; > diff otherwise unchanged. OK millert@ - todd
mpip(4): MPLS "IP Layer2 Transport" pseudowire interface
according to the pwe3 type registry, you can use a pseudowire as a
transport for ip packets. LDP can negotiate this (not ldpd yet) as type
0x000b, but you basically end up with a p2p ip tunnel over an mpls
fabric.
this can be handy if you just want to join two sites together and might
mean you don't have to configure a whole extra routing protocol to get
connectivity up. the existing pwe3 ioctls can be used to configure this
interface, and ldpd support will be forthcoming.
can someone tell me if the conf/files bit makes sense?
ok?
Index: conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.666
diff -u -p -r1.666 files
--- conf/files 20 Dec 2018 23:00:55 - 1.666
+++ conf/files 26 Feb 2019 03:46:02 -
@@ -59,6 +59,7 @@ defineonewire_bitbang
# net device attributes - we have generic code for ether(net)
define crypto
define ether
+define mpls
define sppp
define wlan
@@ -563,6 +564,7 @@ pseudo-device crypto: ifnet
pseudo-device trunk: ifnet, ether, ifmedia
pseudo-device mpe: ifnet, ether
pseudo-device mpw: ifnet, ether
+pseudo-device mpip: ifnet, mpls
pseudo-device bpe: ifnet, ether, ifmedia
pseudo-device vether: ifnet, ether
pseudo-device pppx: ifnet
@@ -814,6 +816,7 @@ file net/if_trunk.c trunk
needs-coun
file net/trunklacp.c trunk
file net/if_mpe.c mpe needs-count
file net/if_mpw.c mpw & bridgeneeds-count
+file net/if_mpip.c mpip
file net/if_bpe.c bpe needs-count
file net/if_vether.c vether needs-count
file net/if_pair.c pairneeds-count
Index: net/if_mpip.c
===
RCS file: net/if_mpip.c
diff -N net/if_mpip.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/if_mpip.c 26 Feb 2019 03:46:02 -
@@ -0,0 +1,706 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2015 Rafael Zalamena
+ * Copyright (c) 2019 David Gwynne
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "bpfilter.h"
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef INET6
+#include
+#endif
+
+#include
+
+#if NBPFILTER > 0
+#include
+#endif /* NBPFILTER */
+
+struct mpip_neighbor {
+ struct shim_hdr n_rshim;
+ struct sockaddr_storage n_nexthop;
+};
+
+struct mpip_softc {
+ struct ifnetsc_if;
+ unsigned intsc_dead;
+ uint32_tsc_flow; /* xor for mbuf flowid */
+
+ struct ifaddr sc_ifa;
+ struct sockaddr_mplssc_smpls; /* Local label */
+ unsigned intsc_rdomain;
+ struct mpip_neighbor*sc_neighbor;
+
+ unsigned intsc_cword; /* control word */
+ unsigned intsc_fword; /* flow-aware transport */
+ int sc_ttl;
+};
+
+void mpipattach(int);
+intmpip_clone_create(struct if_clone *, int);
+intmpip_clone_destroy(struct ifnet *);
+intmpip_ioctl(struct ifnet *, u_long, caddr_t);
+intmpip_output(struct ifnet *, struct mbuf *, struct sockaddr *,
+ struct rtentry *);
+void mpip_start(struct ifnet *);
+
+struct if_clone mpip_cloner =
+IF_CLONE_INITIALIZER("mpip", mpip_clone_create, mpip_clone_destroy);
+
+void
+mpipattach(int n)
+{
+ if_clone_attach(&mpip_cloner);
+}
+
+int
+mpip_clone_create(struct if_clone *ifc, int unit)
+{
+ struct mpip_softc *sc;
+ struct ifnet *ifp;
+
+ sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_CANFAIL|M_ZERO);
+ if (sc == NULL)
+ return (ENOMEM);
+
+ sc->sc_neighbor = 0;
+ sc->sc_cword = 0; /* default to no control word */
+ sc->sc_fword = 0; /* both sides have to agree on FAT first */
+ sc->sc_flow = arc4random() & 0xf;
+ sc->sc_smpls.smpls_len = sizeof(sc->sc_smpls);
+ sc->sc_smpls.smpls_family = AF_MPLS;
+ sc->sc_ttl = -1;
+
+ ifp = &sc->sc_if;
+ snprintf(ifp->i
robots(6): unused score file
The score file was changed to $HOME three years ago.
Index: Makefile
===
RCS file: /cvs/src/games/robots/Makefile,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile
--- Makefile24 Nov 2015 03:10:10 - 1.11
+++ Makefile26 Feb 2019 05:51:16 -
@@ -8,8 +8,4 @@ MAN=robots.6
DPADD= ${LIBCURSES}
LDADD= -lcurses
-beforeinstall:
- ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 664 /dev/null \
- ${DESTDIR}/var/games/robots_roll
-
.include
Re: robots(6): unused score file
On Sun, Feb 24, 2019 at 06:02:58PM -0600, Randy Hartman wrote: > The score file was changed to $HOME three years ago. Indeed. Thanks!
Re: start cleaning up UTF-8 processing in less(1)
Looks good, ok nicm
On Tue, Feb 26, 2019 at 02:39:14AM +0100, Ingo Schwarze wrote:
> Hi Todd,
>
> Todd C. Miller wrote on Mon, Feb 25, 2019 at 01:06:02PM -0700:
> > On Mon, 25 Feb 2019 19:43:36 +0100, Ingo Schwarze wrote:
> >> Todd C. Miller wrote on Mon, Feb 25, 2019 at 09:45:12AM -0700:
> >>> On Mon, 25 Feb 2019 12:39:41 +0100, Ingo Schwarze wrote:
>
> Index: line.c
> >> [...]
> @@ -469,11 +469,10 @@ in_ansi_esc_seq(void)
> * Search backwards for either an ESC (which means we ARE in a
> seq);
> * or an end char (which means we're NOT in a seq).
> */
> -for (p = &linebuf[curr]; p > linebuf; ) {
> -LWCHAR ch = step_char(&p, -1, linebuf);
> -if (IS_CSI_START(ch))
> +for (p = linebuf + curr - 1; p >= linebuf; p--) {
>
> >>> Since curr can be 0, can this lead to be a single byte underflow?
>
> >> No, in that case (which logically means the line buffer is empty),
> >> the end condition p >= linebuf is false right away, the loop
> >> is never entered, the function returns 0 right away and at the
> >> call site, the first if brach (containing "curr--") isn't entered
> >> either.
>
> > Strictly speaking, the result of "p = linebuf + curr - 1" is undefined
> > when curr < 1. There is a special case in the standard when the
> > result is one past the end of an array but no corresponding case
> > for one element before the array. In practice, it is unlikely to
> > matter.
>
> Ouch, i keep forgetting that one, thanks for reminding me.
>
> In that case, let's just use an index rather than a pointer;
> diff otherwise unchanged.
>
> OK?
> Ingo
>
>
> Index: cvt.c
> ===
> RCS file: /cvs/src/usr.bin/less/cvt.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 cvt.c
> --- cvt.c 17 Sep 2016 15:06:41 - 1.8
> +++ cvt.c 26 Feb 2019 01:31:31 -
> @@ -77,7 +77,7 @@ cvt_text(char *odst, char *osrc, int *ch
> dst--;
> } while (dst > odst &&
> !IS_ASCII_OCTET(*dst) && !IS_UTF8_LEAD(*dst));
> - } else if ((ops & CVT_ANSI) && IS_CSI_START(ch)) {
> + } else if ((ops & CVT_ANSI) && ch == ESC) {
> /* Skip to end of ANSI escape sequence. */
> src++; /* skip the CSI start char */
> while (src < src_end)
> Index: filename.c
> ===
> RCS file: /cvs/src/usr.bin/less/filename.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 filename.c
> --- filename.c29 Oct 2017 17:10:55 - 1.26
> +++ filename.c26 Feb 2019 01:31:31 -
> @@ -348,7 +348,7 @@ bin_file(int f)
> pend = &data[n];
> for (p = data; p < pend; ) {
> LWCHAR c = step_char(&p, +1, pend);
> - if (ctldisp == OPT_ONPLUS && IS_CSI_START(c)) {
> + if (ctldisp == OPT_ONPLUS && c == ESC) {
> do {
> c = step_char(&p, +1, pend);
> } while (p < pend && is_ansi_middle(c));
> Index: less.h
> ===
> RCS file: /cvs/src/usr.bin/less/less.h,v
> retrieving revision 1.28
> diff -u -p -r1.28 less.h
> --- less.h30 Dec 2018 23:09:58 - 1.28
> +++ less.h26 Feb 2019 01:31:31 -
> @@ -38,8 +38,6 @@
> #define IS_SPACE(c) isspace((unsigned char)(c))
> #define IS_DIGIT(c) isdigit((unsigned char)(c))
>
> -#define IS_CSI_START(c) (((LWCHAR)(c)) == ESC || (((LWCHAR)(c)) == CSI))
> -
> #ifndef TRUE
> #define TRUE1
> #endif
> @@ -151,9 +149,7 @@ struct textlist {
> #define AT_INDET(1 << 7) /* Indeterminate: either bold or
> underline */
>
> #define CONTROL(c) ((c)&037)
> -
> #define ESC CONTROL('[')
> -#define CSI ((unsigned char)'\233')
>
> #define S_INTERRUPT 01
> #define S_STOP 02
> Index: line.c
> ===
> RCS file: /cvs/src/usr.bin/less/line.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 line.c
> --- line.c24 Feb 2019 04:54:36 - 1.23
> +++ line.c26 Feb 2019 01:31:31 -
> @@ -230,7 +230,7 @@ pshift(int shift)
>*/
> while (shifted <= shift && from < curr) {
> c = linebuf[from];
> - if (ctldisp == OPT_ONPLUS && IS_CSI_START(c)) {
> + if (ctldisp == OPT_ONPLUS && c == ESC) {
> /* Keep cumulative effect. */
> linebuf[to] = c;
> attr[to++] = attr[from++];
> @@ -463,17 +463,16 @@ backc(void)
> static int
> in_ansi_esc_seq(void)
> {
> - char *p;
> + int i;
>
> /*
>* Search backwa
