Re: /dev/full
You clearly do. You're replying to it, and seem to have strong feelings on the matter. On Thu, Mar 02, 2023 at 07:18:41PM -0700, Theo de Raadt wrote: > Does anyone give a shit, besides you?
Re: Questions about the code review process in OpenBSD
On Mon, Nov 07, 2022 at 03:48:27AM +0100, i...@tutanota.com wrote: > > I'm sorry I cannot communicate any longer with you because you won't> give > > assurances that your company doesn't have really terrible> practices.> > > > Or, maybe you are just speaking dishonestly.I am literally laughing my ass > > of, you haven't changed a bit sinceback in 1996 with the FreeBSD vs. Linux > > discussion and your constantchildish behavior. > >From what I can tell, he's just giving you a personal demonstration of his code review style? I can't tell the difference anyway.
Re: sysupgrade: exit 1 instead of exit 0 when ending early
On Tue, Oct 11, 2022 at 01:32:43PM +0200, Janne Johansson wrote: > > On Mon, Oct 10, 2022 at 11:17:32AM -0600, Theo de Raadt wrote: > > > It's been explained a few times that being up-to-date is not an error. > > > It's a good thing, and no action is neccessary when up-to-date. > > > Any non-zero value indicates an error, that would include 2. You are > > > marking this as an error, when it isn't. > > > > It's been said that being up-to-date is not an error, but if it's been > > explained, I've failed to find an explanation. > > > > Usually, when a utility fails to perform its intended task, it gives an > > error. > > I don't personally care what exit code it throws, I only use the tool > > manually, I'd just like to know the rationale if anyone cares to > > elaborate. > > Simplest explanation is probably: > > ./some-program && do something on success > > If you understand this part of shell scripting, then you would see why > returning > 2 (or 1 or 3 or 102444) will throw off the logic, especially if 1 > means some kind > of error. > > As for "intended task", sysupgrade might be viewed as a tool to make > sure you have > the latest it knows about. If no upgrade is needed or the mirror is > old, then that task is done. > > Someone else might think it is a tool to stress the network and disk > by always downloading > things from the internet, and that it is a grave error if this can't > be done, but those people > would have a view that differs from the obsd devs idea of what to use > sysupgrade for. > > Also, if you replace your "mkdir /foo with missing /foo" with "install > -d /foo", you'd see it can > run twice without throwing errors. It makes sure a dir named foo is > created if not exists. > That is its task when run with -d. And you can && a command behind it > so it catches errors > if a file/pipe/socket is there instead. Or add -p to mkdir to get the > same behaviour. > > -- > May the most significant bit of your life be positive. Aha. I didn't know install worked that way (though mkdir -p does too, now that I think of it). I guess my actual confusion was perhaps due to this behavior being implied whereas other utilities are rather explicit about it, at least in terms of man files. Thanks!
Re: sysupgrade: exit 1 instead of exit 0 when ending early
On Tue, Oct 11, 2022 at 01:34:08PM +0200, Renaud Allard wrote: > > > On 10/11/22 13:10, bug wrote: > > On Mon, Oct 10, 2022 at 11:17:32AM -0600, Theo de Raadt wrote: > > > It's been explained a few times that being up-to-date is not an error. > > > It's a good thing, and no action is neccessary when up-to-date. > > > > > > Any non-zero value indicates an error, that would include 2. You are > > > marking this as an error, when it isn't. > > > > It's been said that being up-to-date is not an error, but if it's been > > explained, I've failed to find an explanation. > > It didn't fail, your system is up-to-date as requested. So, it's successful. > > > > > Usually, when a utility fails to perform its intended task, it gives an > > error. This includes when the task is not necessary, e.g. using rm to > > remove a file which doesn't exist, using mkdir to make a directory which > > already exists, or using gzip to compress a file that wouldn't benefit > > from compression (unless you tell it to do so anyway, of course). > > > > I'm not an expert on sysupgrade, but it seems to me like it could in > > fact fail incorrectly if one's system is pointed to a mirror that, for > > whatever reason, is itself outdated. In a macabre sense, this is > > inevitable if one maintains an older copy of OpenBSD that outlives > > OpenBSD itself, as URLs are not permanent. > > And how is it supposed to know your mirror is out of date? Giving an error > there won't help as if your mirror is outdated, it will also tell you that > your system is up to date as of this mirror. > Besides, for some testing purposes, you might need an outdated repo. > > > > > Given all this, I don't understand why it's a "good thing" if sysupgrade > > decides partway through that it doesn't need to do anything after all. > > It did things, it verified your system was up-to-date as you asked. > > > > > I don't personally care what exit code it throws, I only use the tool > > manually, I'd just like to know the rationale if anyone cares to > > elaborate. > > After reading the script, I'd nitpick that it merely advances the version by one step rather than ensures the system is up-to-date, but I suppose one could then argue that somehow advancing beyond the latest version would be incorrect (nevermind impossible), thus leaving "doing nothing" as the only correct action. In any case, thank you for the explanation!
Re: sysupgrade: exit 1 instead of exit 0 when ending early
On Mon, Oct 10, 2022 at 11:17:32AM -0600, Theo de Raadt wrote: > It's been explained a few times that being up-to-date is not an error. > It's a good thing, and no action is neccessary when up-to-date. > > Any non-zero value indicates an error, that would include 2. You are > marking this as an error, when it isn't. It's been said that being up-to-date is not an error, but if it's been explained, I've failed to find an explanation. Usually, when a utility fails to perform its intended task, it gives an error. This includes when the task is not necessary, e.g. using rm to remove a file which doesn't exist, using mkdir to make a directory which already exists, or using gzip to compress a file that wouldn't benefit from compression (unless you tell it to do so anyway, of course). I'm not an expert on sysupgrade, but it seems to me like it could in fact fail incorrectly if one's system is pointed to a mirror that, for whatever reason, is itself outdated. In a macabre sense, this is inevitable if one maintains an older copy of OpenBSD that outlives OpenBSD itself, as URLs are not permanent. Given all this, I don't understand why it's a "good thing" if sysupgrade decides partway through that it doesn't need to do anything after all. I don't personally care what exit code it throws, I only use the tool manually, I'd just like to know the rationale if anyone cares to elaborate.
Re: USB string descriptor requests
There doesn't seem to be much interest in this problem, so I'll just use
this change locally to solve my issue.
Though isn't it a tiny buffer overflow if a malicious or broken USB
device sends a bLength of 255 and actually follows through with it?
usb_string_descriptor_t is only 254 bytes.
On Sun, Aug 21, 2022 at 12:35:00AM -0400, bug wrote:
> I got a StarTech SV431USBDDM KVM switch, and it specifically mangles the
> string descriptor responses for my keyboard (which otherwise works just
> fine) when probed about the vendor string after plugging in or resetting
> the device.
>
> After a ton of messing around, I also found out that this problem just
> isn't happening at all if OpenBSD only sends a single string descriptor
> request with the maximum possible length, rather than two as it
> currently does.
>
> According to the USB 2.0 and 3.2 specs, devices that receive a larger
> wLength than the descriptor's actual length /should/ just send the full
> descriptor in a short packet. Of course, the current behavior isn't
> wrong either, if the wLength is shorter, then only the initial bytes or
> length (depending on the spec) /should/ be sent.
>
> (So unless there's some deeper bug in OpenBSD, my KVM switch is totally
> dropping the ball either way. I'll probably post about it on Misc later,
> unless details are desired here...)
>
> But I'm curious if there's a reason for sending two separate packets
> when one should be fine. Do certain USB devices expect it that way?
>
> I suppose it seems Windows does it this way too (the only reason the
> switch works there is because they neglect to check the vendor string),
> so the answer to that could very well be a hard yes...
>
> This is my first post, so sorry in advance if I did anything dumb. Diff
> provided for context.
>
>
> Index: usb_subr.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
> retrieving revision 1.158
> diff -u -p -r1.158 usb_subr.c
> --- usb_subr.c16 Feb 2022 06:23:42 - 1.158
> +++ usb_subr.c21 Aug 2022 03:33:10 -
> @@ -125,20 +125,17 @@ usbd_get_string_desc(struct usbd_device
> req.bRequest = UR_GET_DESCRIPTOR;
> USETW2(req.wValue, UDESC_STRING, sindex);
> USETW(req.wIndex, langid);
> - USETW(req.wLength, 2); /* size and descriptor type first */
> + USETW(req.wLength, sizeof(*sdesc)); /* size and descriptor type
> first */
> +
> err = usbd_do_request_flags(dev, , sdesc, USBD_SHORT_XFER_OK,
> , USBD_DEFAULT_TIMEOUT);
> +
> if (err)
> return (err);
>
> if (actlen < 2)
> return (USBD_SHORT_XFER);
>
> - USETW(req.wLength, sdesc->bLength); /* the whole string */
> - err = usbd_do_request_flags(dev, , sdesc, USBD_SHORT_XFER_OK,
> - , USBD_DEFAULT_TIMEOUT);
> - if (err)
> - return (err);
>
> if (actlen != sdesc->bLength) {
> DPRINTFN(-1, ("%s: expected %d, got %d\n", __func__,
>
USB string descriptor requests
I got a StarTech SV431USBDDM KVM switch, and it specifically mangles the
string descriptor responses for my keyboard (which otherwise works just
fine) when probed about the vendor string after plugging in or resetting
the device.
After a ton of messing around, I also found out that this problem just
isn't happening at all if OpenBSD only sends a single string descriptor
request with the maximum possible length, rather than two as it
currently does.
According to the USB 2.0 and 3.2 specs, devices that receive a larger
wLength than the descriptor's actual length /should/ just send the full
descriptor in a short packet. Of course, the current behavior isn't
wrong either, if the wLength is shorter, then only the initial bytes or
length (depending on the spec) /should/ be sent.
(So unless there's some deeper bug in OpenBSD, my KVM switch is totally
dropping the ball either way. I'll probably post about it on Misc later,
unless details are desired here...)
But I'm curious if there's a reason for sending two separate packets
when one should be fine. Do certain USB devices expect it that way?
I suppose it seems Windows does it this way too (the only reason the
switch works there is because they neglect to check the vendor string),
so the answer to that could very well be a hard yes...
This is my first post, so sorry in advance if I did anything dumb. Diff
provided for context.
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.158
diff -u -p -r1.158 usb_subr.c
--- usb_subr.c 16 Feb 2022 06:23:42 - 1.158
+++ usb_subr.c 21 Aug 2022 03:33:10 -
@@ -125,20 +125,17 @@ usbd_get_string_desc(struct usbd_device
req.bRequest = UR_GET_DESCRIPTOR;
USETW2(req.wValue, UDESC_STRING, sindex);
USETW(req.wIndex, langid);
- USETW(req.wLength, 2); /* size and descriptor type first */
+ USETW(req.wLength, sizeof(*sdesc)); /* size and descriptor type
first */
+
err = usbd_do_request_flags(dev, , sdesc, USBD_SHORT_XFER_OK,
, USBD_DEFAULT_TIMEOUT);
+
if (err)
return (err);
if (actlen < 2)
return (USBD_SHORT_XFER);
- USETW(req.wLength, sdesc->bLength); /* the whole string */
- err = usbd_do_request_flags(dev, , sdesc, USBD_SHORT_XFER_OK,
- , USBD_DEFAULT_TIMEOUT);
- if (err)
- return (err);
if (actlen != sdesc->bLength) {
DPRINTFN(-1, ("%s: expected %d, got %d\n", __func__,
