acpiapplesmc(4)
This is an initial driver for the Apple System Management Controller found in Intel based Apple computers. The driver is currently missing support for the Sudden Motion Sensor (SMS), light sensor, and keyboard backlight since I don't have that hardware available to develop on. On my iMac11,2 it can deliver fan and temperatures values: hw.sensors.acpiapplesmc0.temp0=24.00 degC (Airflow 1) hw.sensors.acpiapplesmc0.temp1=33.00 degC (CPU Core 0) hw.sensors.acpiapplesmc0.temp2=36.00 degC (CPU Heatsink) hw.sensors.acpiapplesmc0.temp3=40.00 degC (CPU Core 1) hw.sensors.acpiapplesmc0.temp4=47.00 degC (GPU) hw.sensors.acpiapplesmc0.temp5=45.00 degC (GPU Heatsink) hw.sensors.acpiapplesmc0.temp6=59.00 degC (PCH) hw.sensors.acpiapplesmc0.temp7=42.00 degC (Memory) hw.sensors.acpiapplesmc0.temp8=45.00 degC (Mainboard Proximity) hw.sensors.acpiapplesmc0.fan0=998 RPM hw.sensors.acpiapplesmc0.fan1=1132 RPM hw.sensors.acpiapplesmc0.fan2=1198 RPM Feedback, testers, OKs? Index: share/man/man4/Makefile === RCS file: /cvs/src/share/man/man4/Makefile,v retrieving revision 1.782 diff -u -p -u -p -r1.782 Makefile --- share/man/man4/Makefile 25 Jun 2020 12:26:31 - 1.782 +++ share/man/man4/Makefile 7 Sep 2020 04:54:57 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.782 2020/06/25 12:26:31 patrick Exp $ MAN= aac.4 abcrtc.4 ac97.4 acphy.4 acrtc.4 \ - acpi.4 acpiac.4 acpials.4 acpiasus.4 acpibat.4 \ + acpi.4 acpiac.4 acpials.4 acpiapplesmc.4 acpiasus.4 acpibat.4 \ acpibtn.4 acpicbkbd.4 acpicpu.4 acpidock.4 acpihve.4 acpiec.4 \ acpihid.4 \ acpihpet.4 acpimadt.4 acpimcfg.4 acpipci.4 acpiprt.4 acpipwrres.4 \ Index: share/man/man4/acpiapplesmc.4 === RCS file: share/man/man4/acpiapplesmc.4 diff -N share/man/man4/acpiapplesmc.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/acpiapplesmc.4 7 Sep 2020 04:54:57 - @@ -0,0 +1,63 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2020 Marcus Glocker +.\" +.\" 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. +.\" +.Dd $Mdocdate: September 07 2020 $ +.Dt APPLESMC 4 +.Os +.Sh NAME +.Nm acpiapplesmc +.Nd Apple System Management Controller +.Sh SYNOPSIS +.Cd "acpiapplesmc* at acpi?" +.Sh DESCRIPTION +The +.Nm +driver provides support for the Apple System Management Controller chipsets +found in Intel based Apple computers. The sensors are exposed through the +.Xr sysctl 8 +interface. +.Pp +The currently supported sensors are: +.Bl -column "CPU power cons." "Units" "Typical Use" -offset indent +.It Sy "Sensor" Ta Sy "Units" Ta Sy "Typical Use" +.It Li "F?Ac" Ta "RPM" Ta "Fan" +.It Li "TA0P" Ta "degC" Ta "Airflow 1" +.It Li "TC0C" Ta "degC" Ta "CPU Core 0" +.It Li "TC0H" Ta "degC" Ta "CPU Heatsink" +.It Li "TC1C" Ta "degC" Ta "CPU Core 1" +.It Li "TG0D" Ta "degC" Ta "GPU" +.It Li "TG0H" Ta "degC" Ta "GPU Heatsink" +.It Li "TPCD" Ta "degC" Ta "PCH" +.It Li "Tm0P" Ta "degC" Ta "Memory" +.It Li "Tm1P" Ta "degC" Ta "Mainboard Proximity" +.El +.Sh SEE ALSO +.Xr acpi 4 , +.Xr sensorsd 8 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 6.8 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Marcus Glocker Aq Mt mgloc...@openbsd.org . +.Sh CAVEATS +The driver is currently missing support for the Sudden Motion Sensor (SMS), +light sensor, and keyboard backlight. Index: sys/dev/acpi/acpiapplesmc.c === RCS file: sys/dev/acpi/acpiapplesmc.c diff -N sys/dev/acpi/acpiapplesmc.c --- /dev/null 1 Jan 1970 00:00:00 - +++ sys/dev/acpi/acpiapplesmc.c 7 Sep 2020 04:54:57 - @@ -0,0 +1,661 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2020 Marcus Glocker + * + * 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
Re: [macppc] clang-10: issue with ppc dag to dag pattern instruction selection
On Tue, Sep 01, 2020 at 07:37:19PM -0400, George Koehler wrote: > Moving from bugs to tech. > > cwen reported that base-clang crashed on macppc in graphics/babl and > emulators/mednafen [1]. I observed that clang crashed on powerpc64 in > mednafen. I now propose to backport a commit in llvm 11.x git [2] to > prevent these crashes. This change affects other arches. > > [1] https://marc.info/?l=openbsd-bugs=159775378014683=2 > [2] https://github.com/llvm/llvm-project/commit/d4ce862 > > FreeBSD on powerpc64 found the problems earlier: > https://bugs.llvm.org/show_bug.cgi?id=45237 (babl) > https://bugs.llvm.org/show_bug.cgi?id=45274 (mednafen) > > The problem is with clang -fno-unsafe-math-optimizations, one of the > new floating-point options in clang-10. The diff disables the new > options on all targets except X86 (and SystemZ), so it also affects > arches other than PowerPC. The disabled options cause a warning. > > With the diff in clang: > - mednafen stops using -fno-unsafe-math-optimizations, because the >new warning fails the configure test. I can build and package >mednafen on macppc (where a single *m68k*.cpp takes over 2 hours), >but when I try to play Super Mario World (snes), mednafen crashes >with a SIGSEGV. The build on powerpc64 stops crashing clang, but >fails at an altivec error. > - babl uses -fno-unsafe-math-optimizations and ignores the new >warning. I can build and package babl, and all 27 tests pass on >both macppc and powerpc64. > - I have built src and xenocara on powerpc64. > > The diff is in llvm 11.x. To backport the diff, I manually applied > some parts (where the context had changed), and I renamed > RoundingMode::NearestTiesToEven back to FPR_RoundToNearest. > > Apply the diff in /usr/src/gnu/llvm. If DiagnosticFrontendKinds.inc > exists under /usr/obj/gnu/usr.bin/clang/, you must delete the .inc, > because there is a missing dependency in our Makefiles. > > Is this OK? Should we do something else? --George This is the upstream patch to clang11 almost verbatim, and with it I can build clang and then use that clang to build a snap, so I think this is good to go. I certainly do not have alternate suggestions, so ok mortimer. Cheers, Todd > > Index: clang/docs/ClangCommandLineReference.rst > === > RCS file: /cvs/src/gnu/llvm/clang/docs/ClangCommandLineReference.rst,v > retrieving revision 1.1.1.2 > diff -u -p -r1.1.1.2 ClangCommandLineReference.rst > --- clang/docs/ClangCommandLineReference.rst 9 Aug 2020 15:51:07 - > 1.1.1.2 > +++ clang/docs/ClangCommandLineReference.rst 30 Aug 2020 19:37:51 - > @@ -818,6 +818,10 @@ Enables the experimental global instruct > > Enables an experimental new pass manager in LLVM. > > +.. option:: -fexperimental-strict-floating-point > + > +Enables the use of non-default rounding modes and non-default exception > handling on targets that are not currently ready. > + > .. option:: -ffine-grained-bitfield-accesses, > -fno-fine-grained-bitfield-accesses > > Use separate accesses for consecutive bitfield runs with legal widths and > alignments. > Index: clang/include/clang/Basic/CodeGenOptions.def > === > RCS file: /cvs/src/gnu/llvm/clang/include/clang/Basic/CodeGenOptions.def,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 CodeGenOptions.def > --- clang/include/clang/Basic/CodeGenOptions.def 3 Aug 2020 14:31:32 > - 1.1.1.1 > +++ clang/include/clang/Basic/CodeGenOptions.def 30 Aug 2020 19:37:51 > - > @@ -58,6 +58,8 @@ CODEGENOPT(DisableLLVMPasses , 1, 0) /// > ///< frontend. > CODEGENOPT(DisableLifetimeMarkers, 1, 0) ///< Don't emit any lifetime markers > CODEGENOPT(DisableO0ImplyOptNone , 1, 0) ///< Don't annonate function with > optnone at O0 > +CODEGENOPT(ExperimentalStrictFloatingPoint, 1, 0) ///< Enables the new, > experimental > + ///< strict floating point. > CODEGENOPT(ExperimentalNewPassManager, 1, 0) ///< Enables the new, > experimental > ///< pass manager. > CODEGENOPT(DebugPassManager, 1, 0) ///< Prints debug information for the new > Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td > === > RCS file: > /cvs/src/gnu/llvm/clang/include/clang/Basic/DiagnosticFrontendKinds.td,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 DiagnosticFrontendKinds.td > --- clang/include/clang/Basic/DiagnosticFrontendKinds.td 3 Aug 2020 > 14:31:32 - 1.1.1.1 > +++ clang/include/clang/Basic/DiagnosticFrontendKinds.td 30 Aug 2020 > 19:37:51 - > @@ -37,6 +37,12 @@ def note_fe_backend_plugin: Note<"%0">, > def warn_fe_override_module : Warning< > "overriding the module target
snmpd refactor listen on grammar
Moving towards individual transport mappings, it's becoming more
convenient to have the protocol directly after the listen on statement.
This gives me more flexibility in using mapping-specific APIs, also
when other transport mappings might become available in the future it
allows for easier mapping-specific features.
While here I decided to also add port support for snmpe, which at this
point is rather trivial. Traphandler is not my point of focus at this
time.
having udp|tcp at the last position is still supported, but generates a
pretty deprecated warning. Probably to be removed after release.
OK?
martijn@
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
retrieving revision 1.60
diff -u -p -r1.60 parse.y
--- parse.y 6 Sep 2020 15:51:28 - 1.60
+++ parse.y 6 Sep 2020 20:08:08 -
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -92,6 +93,7 @@ char *symget(const char *);
struct snmpd *conf = NULL;
static int errors = 0;
static struct usmuser *user = NULL;
+static char*snmpd_port = SNMPD_PORT;
int host(const char *, const char *, int,
struct sockaddr_storage *, int);
@@ -122,11 +124,11 @@ typedef struct {
%token SYSTEM CONTACT DESCR LOCATION NAME OBJECTID SERVICES RTFILTER
%token READONLY READWRITE OCTETSTRING INTEGER COMMUNITY TRAP RECEIVER
%token SECLEVEL NONE AUTH ENC USER AUTHKEY ENCKEY ERROR DISABLED
-%token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER
+%token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER PORT
%token STRING
%token NUMBER
%typehostcmn
-%typesrcaddr
+%typesrcaddr port
%typeoptwrite yesno seclevel proto
%type objtype cmd
%type oid hostoid trapoid
@@ -193,28 +195,7 @@ yesno : STRING {
}
;
-main : LISTEN ON STRING proto{
- struct sockaddr_storage ss[16];
- int nhosts, i;
-
- nhosts = host($3, SNMPD_PORT, $4, ss, nitems(ss));
- if (nhosts < 1) {
- yyerror("invalid address: %s", $3);
- free($3);
- YYERROR;
- }
- if (nhosts > (int)nitems(ss))
- log_warn("%s resolves to more than %zu hosts",
- $3, nitems(ss));
- free($3);
-
- for (i = 0; i < nhosts; i++) {
- if (listen_add(&(ss[i]), $4) == -1) {
- yyerror("calloc");
- YYERROR;
- }
- }
- }
+main : LISTEN ON listenproto
| READONLY COMMUNITY STRING {
if (strlcpy(conf->sc_rdcommunity, $3,
sizeof(conf->sc_rdcommunity)) >=
@@ -295,6 +276,128 @@ main : LISTEN ON STRING proto{
}
;
+listenproto: UDP listen_udp
+ | TCP listen_tcp
+ | listen_empty
+
+listen_udp : STRING port {
+ struct sockaddr_storage ss[16];
+ int nhosts, i;
+
+ nhosts = host($1, $2, SOCK_DGRAM, ss, nitems(ss));
+ if (nhosts < 1) {
+ yyerror("invalid address: %s", $1);
+ free($1);
+ if ($2 != snmpd_port)
+ free($2);
+ YYERROR;
+ }
+ if (nhosts > (int)nitems(ss))
+ log_warn("%s:%s resolves to more than %zu
hosts",
+ $1, $2, nitems(ss));
+
+ free($1);
+ if ($2 != snmpd_port)
+ free($2);
+ for (i = 0; i < nhosts; i++) {
+ if (listen_add(&(ss[i]), SOCK_DGRAM) == -1) {
+ yyerror("calloc");
+ YYERROR;
+ }
+ }
+ }
+
+listen_tcp : STRING port {
+ struct sockaddr_storage ss[16];
+ int nhosts, i;
+
+ nhosts = host($1, $2, SOCK_STREAM, ss, nitems(ss));
+ if (nhosts < 1) {
+ yyerror("invalid address: %s", $1);
+ free($1);
+
Re: [WIP FAQ13] New section for webcam usage
Stefan Hagen wrote: > Using a webcam as user > > > To use the webcam as regular user, you need to change the device > permissions. Only root is allowed to access video devices by default. > > > One way of allowing your user to access the video devices is to change > the permissions from ~/.xsession. You can configure > https://man.openbsd.org/doas;>doas(1) to perform > https://man.openbsd.org/chmod;>chmod(1) as superuser > without asking for a password for your user. > > > Then add the following line to your ~/.xsession: > > > doas chown $USER /dev/video0 > What do you think about adding a group "_video" to the default install and add /dev/video* devices to it with perm. 660. This would allow us to simply instruct users to add their user to group _video to give them access to video devices. Best Regards, Stefan
[WIP FAQ13] New section for webcam usage
Hello, Lauries video(1) email to misc@ encouraged me to take this information and try to come up with a proposal to enhance the multimedia faq with information about webcam usage. It's the first time I'm working on a faq article and I don't know about any style guides. I tried to align with the articles already written. Please educate me about the parts I missed. I'm not sure where people working on documentation collaborate. So I'm trying my luck here on tech@. My proposal is online and I'm also inlining it (not as patch for easier consumption): https://codevoid.de/h/wip_webcamfaq13.html I'm sure some parts need refinement / better wording. The part I'm mostly unsure about is how to correctly give the user permissions to the video devices. Most people probably do it the way I described (doas chmod $USER in .xsession). Once it's good enough to get committed, I'll create a proper patch. Any thoughts on it? Thanks in advance, Stefan Using a Webcam Supported Hardware Most webcams today work according to the USB Video Class (UVC) specification, which is supported by the https://man.openbsd.org/uvideo;>uvideo(4) device driver and attaches to the https://man.openbsd.org/video.4;>video(4) device. The manpage lists some supported devices, but there is a good chance that other devices work as well. For example, webcams in Lenovo Thinkpads laptops do usually work. A supported webcam (or other video device) shows up in dmesg like this: uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10 video0 at uvideo0 uvideo1 at uhub0 port 8 configuration 1 interface 2 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10 video1 at uvideo1 You see that an uvideo device was detected and has been attached to video0. This device will be accessible through /dev/video0. Modern laptops sometimes attach a second video device, which is the infrared camera for face recognition. The second camera does not produce a usable video stream. You can find the usable camera with the https://man.openbsd.org/video;>video(1) command: $ video -q -f /dev/video0 video device /dev/video0: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 320x180: 30 320x240: 30 352x288: 30 424x240: 30 640x360: 30 640x480: 30 848x480: 20 960x540: 15 1280x720: 10 controls: brightness, contrast, saturation, hue, gamma, sharpness, white_balance_temperature $ video -q -f /dev/video1 video: /dev/video1 has no usable YUV encodings The usable camera device shows supported resolutions and framerates. Note that the framerates only apply to the uncompressed YUY2 stream. More on that in Recording a webcam stream. Using a webcam as user To use the webcam as regular user, you need to change the device permissions. Only root is allowed to access video devices by default. One way of allowing your user to access the video devices is to change the permissions from ~/.xsession. You can configure https://man.openbsd.org/doas;>doas(1) to perform https://man.openbsd.org/chmod;>chmod(1) as superuser without asking for a password for your user. Then add the following line to your ~/.xsession: doas chown $USER /dev/video0 If you're not using https://man.openbsd.org/xenodm;>xenodm(1) and you are starting your X session with https://man.openbsd.org/startx;>startx(1), you can accomplish the same with https://man.openbsd.org/fbtab;>fbtab(5). Example entry in /etc/fbtab: /dev/ttyC0 0600/dev/video0 Recording a webcam stream This section uses ffplay and ffmpeg from graphics/ffmpeg. To find out what your camera is capable of, run the following command: $ ffplay -f v4l2 -list_formats all -i /dev/video0 [...] [video4linux2,v4l2 @ 0x921f8420800] Compressed: mjpeg : MJPEG : 1280x720 320x180 320x240 352x288 424x240 640x360 640x480 848x480 960x540 [video4linux2,v4l2 @ 0x921f8420800] Raw : yuyv422 : YUYV : 640x480 320x180 320x240 352x288 424x240 640x360 848x480 960x540 1280x720 At the end of the output, you'll find two lines similiar to the two above. The first line shows resolutions supported in the uncompressed YUYV format. The frame rates in this format can be very low. The second line shows the supported MJPEG compressed video resolutions, which deliver much higher framerates (usually 30fps or 60fps). Now try to play the webcam stream. Choose one of the MJPEG resolutions and run: $ ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 [...] Input #0, video4linux2,v4l2, from '/dev/video0':B sq=0B f=0/0 Duration: N/A, start: 1599377893.546533, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 30 fps, 30 tbr, 1000k tbn, 1000k tbc The webcam stream should be displayed. Ffplay also shows the used resolution and the framerate (fps) used. If this works, you can go
Re: snmpd remove snmpe_dispatch_parent
On Sun, Sep 06, 2020 at 06:37:17PM +0200, Martijn van Duren wrote:
> going for another easy picking: snmpe_dispatch_parent is just an empty
> stub. proc.c assigns proc_dispatch_null to p_cb if it's null, which
> effectively does the same thing.
>
> OK?
>
OK denis@
> martijn@
>
> Index: snmpe.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 snmpe.c
> --- snmpe.c 6 Sep 2020 15:51:28 - 1.66
> +++ snmpe.c 6 Sep 2020 16:37:10 -
> @@ -46,7 +46,6 @@ void snmpe_tryparse(int, struct snmp_me
> int snmpe_parsevarbinds(struct snmp_message *);
> void snmpe_response(struct snmp_message *);
> void snmpe_sig_handler(int sig, short, void *);
> -int snmpe_dispatch_parent(int, struct privsep_proc *, struct imsg *);
> int snmpe_bind(struct address *);
> void snmpe_recvmsg(int fd, short, void *);
> void snmpe_readcb(int fd, short, void *);
> @@ -60,7 +59,7 @@ struct imsgev *iev_parent;
> static const struct timeval snmpe_tcp_timeout = { 10, 0 }; /* 10s */
>
> static struct privsep_proc procs[] = {
> - { "parent", PROC_PARENT,snmpe_dispatch_parent }
> + { "parent", PROC_PARENT }
> };
>
> void
> @@ -133,17 +132,6 @@ snmpe_shutdown(void)
> close(h->fd);
> }
> kr_shutdown();
> -}
> -
> -int
> -snmpe_dispatch_parent(int fd, struct privsep_proc *p, struct imsg *imsg)
> -{
> - switch (imsg->hdr.type) {
> - default:
> - break;
> - }
> -
> - return (-1);
> }
>
> int
>
snmpd remove snmpe_dispatch_parent
going for another easy picking: snmpe_dispatch_parent is just an empty
stub. proc.c assigns proc_dispatch_null to p_cb if it's null, which
effectively does the same thing.
OK?
martijn@
Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.66
diff -u -p -r1.66 snmpe.c
--- snmpe.c 6 Sep 2020 15:51:28 - 1.66
+++ snmpe.c 6 Sep 2020 16:37:10 -
@@ -46,7 +46,6 @@ void snmpe_tryparse(int, struct snmp_me
int snmpe_parsevarbinds(struct snmp_message *);
voidsnmpe_response(struct snmp_message *);
voidsnmpe_sig_handler(int sig, short, void *);
-int snmpe_dispatch_parent(int, struct privsep_proc *, struct imsg *);
int snmpe_bind(struct address *);
voidsnmpe_recvmsg(int fd, short, void *);
voidsnmpe_readcb(int fd, short, void *);
@@ -60,7 +59,7 @@ struct imsgev *iev_parent;
static const struct timevalsnmpe_tcp_timeout = { 10, 0 }; /* 10s */
static struct privsep_proc procs[] = {
- { "parent", PROC_PARENT,snmpe_dispatch_parent }
+ { "parent", PROC_PARENT }
};
void
@@ -133,17 +132,6 @@ snmpe_shutdown(void)
close(h->fd);
}
kr_shutdown();
-}
-
-int
-snmpe_dispatch_parent(int fd, struct privsep_proc *p, struct imsg *imsg)
-{
- switch (imsg->hdr.type) {
- default:
- break;
- }
-
- return (-1);
}
int
Re: run(4): crash still observed on 6.7 and -current
On Sun, Sep 06, 2020 at 05:19:46PM +0530, Neeraj Pal wrote: > Hi there, > > I have found that the crash is still observed which had already been > discussed, here, > https://marc.info/?l=openbsd-tech=143662082630187=2 on -current > and also on 6.7 > > also verified that the patch > (https://marc.info/?l=openbsd-tech=143693266301743=2) sent by > @stefan fixes the problem for me on -current. > > regards, > Neeraj > > I have looked over that old thread, and looking at it back today I see that none of the proposed diffs look perfect. Somebody will have to take a fresh look at this. Please file a new bug report for the issue, including crash information and a dmesg.
smtpd.conf add admd keyword
EHLO,
RFC8601 defines the authentication-results header which can be used to
show the verification-results of DKIM, SPF, DMARC, and others.
I can think of quite a few filters that could be build around this
header:
- the prior mentioned
- detecting the header before accepting it into ones ADMD
- using it to calculate some sort of spam-score by some other filter
These are the 3 main categories that spring to mind, with especially
the first one having the option to be split in quite a few different
filters on itself.
Since setting the authservid on every of these filters (once they
arrive) will be cumbersome and error-prone I would like to propose to
distribute this value from a single point in the smtpd.conf.
I already have a filter-admdscrub basically ready and I'm working on a
filter-dkimverify every now and then (no where near done yet) which can
use this feature.
OK?
martijn@
Index: lka_filter.c
===
RCS file: /cvs/src/usr.sbin/smtpd/lka_filter.c,v
retrieving revision 1.62
diff -u -p -r1.62 lka_filter.c
--- lka_filter.c24 Apr 2020 11:34:07 - 1.62
+++ lka_filter.c6 Sep 2020 15:05:21 -
@@ -210,6 +210,8 @@ lka_proc_config(struct processor_instanc
io_printf(pi->io, "config|subsystem|smtp-in\n");
if (pi->subsystems & FILTER_SUBSYSTEM_SMTP_OUT)
io_printf(pi->io, "config|subsystem|smtp-out\n");
+ io_printf(pi->io, "config|admd|%s\n",
+ env->sc_admd != NULL ? env->sc_admd : env->sc_hostname);
io_printf(pi->io, "config|ready\n");
}
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/smtpd/parse.y,v
retrieving revision 1.278
diff -u -p -r1.278 parse.y
--- parse.y 1 Jun 2020 05:21:30 - 1.278
+++ parse.y 6 Sep 2020 15:05:21 -
@@ -173,7 +173,7 @@ typedef struct {
%}
-%token ACTION ALIAS ANY ARROW AUTH AUTH_OPTIONAL
+%token ACTION ADMD ALIAS ANY ARROW AUTH AUTH_OPTIONAL
%token BACKUP BOUNCE BYPASS
%token CA CERT CHAIN CHROOT CIPHERS COMMIT COMPRESSION CONNECT
%token DATA DATA_LINE DHE DISCONNECT DOMAIN
@@ -209,6 +209,7 @@ grammar : /* empty */
| grammar include '\n'
| grammar varset '\n'
| grammar bounce '\n'
+ | grammar admd '\n'
| grammar ca '\n'
| grammar mda '\n'
| grammar mta '\n'
@@ -310,6 +311,21 @@ BOUNCE WARN_INTERVAL {
;
+admd:
+ADMD STRING {
+ size_t i;
+
+ for (i = 0; $2[i] != '\0'; i++) {
+ if (!isprint($2[i])) {
+ yyerror("not a valid admd");
+ free($2);
+ YYERROR;
+ }
+ }
+ conf->sc_admd = $2;
+};
+
+
ca:
CA STRING {
char buf[HOST_NAME_MAX+1];
@@ -2603,6 +2619,7 @@ lookup(char *s)
/* this has to be sorted always */
static const struct keywords keywords[] = {
{ "action", ACTION },
+ { "admd", ADMD },
{ "alias", ALIAS },
{ "any",ANY },
{ "auth", AUTH },
Index: smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.251
diff -u -p -r1.251 smtpd.conf.5
--- smtpd.conf.527 Aug 2020 08:58:30 - 1.251
+++ smtpd.conf.56 Sep 2020 15:05:21 -
@@ -313,6 +313,11 @@ which is useful on machines with multipl
If the list contains more than one address, all of them are used
in such a way that traffic is routed as efficiently as possible.
.El
+.It Ic admd Ar authservid
+The Administrative Management Domain this mailserver belongs to.
+The authservid will be forwarded to filters using it to identify or mark
+authentication-results headers.
+If omitted it defaults to the server name.
.It Ic bounce Cm warn-interval Ar delay Op , Ar delay ...
Send warning messages to the envelope sender when temporary delivery
failures cause a message to remain on the queue for longer than
Index: smtpd.h
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.h,v
retrieving revision 1.656
diff -u -p -r1.656 smtpd.h
--- smtpd.h 8 Apr 2020 07:30:44 - 1.656
+++ smtpd.h 6 Sep 2020 15:05:21 -
@@ -624,6 +624,8 @@ struct smtpd {
char *sc_srs_key;
char *sc_srs_key_backup;
int sc_srs_ttl;
+
+ char *sc_admd;
};
#defineTRACE_DEBUG 0x0001
run(4): crash still observed on 6.7 and -current
Hi there, I have found that the crash is still observed which had already been discussed, here, https://marc.info/?l=openbsd-tech=143662082630187=2 on -current and also on 6.7 also verified that the patch (https://marc.info/?l=openbsd-tech=143693266301743=2) sent by @stefan fixes the problem for me on -current. regards, Neeraj
Re: ftp: allow specifying supported protocols
On Sun, Sep 06 2020, Theo Buehler wrote:
> On Sun, Sep 06, 2020 at 12:55:17AM +0200, Jeremie Courreges-Anglas wrote:
>> On Sat, Sep 05 2020, Theo Buehler wrote:
>> > I found this small diff useful more than once (admittedly for debugging).
>> > It allows specifying the protocols that may be used by ftp the same way
>> > as nc -Tprotocols works. For example:
>> >
>> > $ ftp -Sprotocols=tlsv1.2:tlsv1.1 https://example.com/file
>> >
>> > Perhaps someone else has use for it, too?
>>
>> I think it's useful indeed. ok jca@
>>
>> One nit below,
>>
>> > Index: ftp.1
>> > ===
>> > RCS file: /var/cvs/src/usr.bin/ftp/ftp.1,v
>> > retrieving revision 1.119
>> > diff -u -p -r1.119 ftp.1
>> > --- ftp.1 11 Feb 2020 18:41:39 - 1.119
>> > +++ ftp.1 5 Sep 2020 18:11:24 -
>> > @@ -261,6 +261,12 @@ Don't perform server certificate validat
>> > Require the server to present a valid OCSP stapling in the TLS handshake.
>> > .It Cm noverifytime
>> > Disable validation of certificate times and OCSP validation.
>> > +.It Cm protocols Ns = Ns Ar protocol_list
>> > +Specify the supported TLS protocols that will be used by
>> > +.Nm
>> > +(see
>> > +.Xr tls_config_parse_protocols 3
>> > +for details).
>> > .It Cm session Ns = Ns Ar /path/to/session
>> > Specify a file to use for TLS session data.
>> > If this file has a non-zero length, the session data will be read from
>> > this file
>> > Index: main.c
>> > ===
>> > RCS file: /var/cvs/src/usr.bin/ftp/main.c,v
>> > retrieving revision 1.132
>> > diff -u -p -r1.132 main.c
>> > --- main.c 1 Sep 2020 12:33:48 - 1.132
>> > +++ main.c 1 Sep 2020 18:13:09 -
>> > @@ -209,6 +209,8 @@ char * const ssl_verify_opts[] = {
>> >"noverifytime",
>> > #define SSL_SESSION 8
>> >"session",
>> > +#define SSL_PROTOCOLS 9
>> > + "protocols",
>> >NULL
>> > };
>> >
>> > @@ -220,6 +222,7 @@ process_ssl_options(char *cp)
>> > {
>> >const char *errstr;
>> >long long depth;
>>
>> (Should probably be an int.)
>>
>> > + uint32_t protocols;
>>
>> Could be moved below str (smaller size on lp64, see style(9)).
>>
>> >char *str;
>
> If we care about this, shouldn't I rather move *str up below *errstr?
Yes. The diff below shows the overall changes I had in mind. Please
pick it up if you like it, or just use your version.
Sorry for the bikeshed color concern, I should have brought this up
later in private (if at all).
Index: main.c
===
RCS file: /d/cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.132
diff -u -p -p -u -r1.132 main.c
--- main.c 1 Sep 2020 12:33:48 - 1.132
+++ main.c 6 Sep 2020 08:26:25 -
@@ -209,6 +209,8 @@ char * const ssl_verify_opts[] = {
"noverifytime",
#define SSL_SESSION8
"session",
+#define SSL_PROTOCOLS 9
+ "protocols",
NULL
};
@@ -219,8 +221,9 @@ static void
process_ssl_options(char *cp)
{
const char *errstr;
- long long depth;
char *str;
+ int depth;
+ uint32_t protocols;
while (*cp) {
switch (getsubopt(, ssl_verify_opts, )) {
@@ -259,7 +262,7 @@ process_ssl_options(char *cp)
if (errstr)
errx(1, "certificate validation depth is %s",
errstr);
- tls_config_set_verify_depth(tls_config, (int)depth);
+ tls_config_set_verify_depth(tls_config, depth);
break;
case SSL_MUSTSTAPLE:
tls_config_ocsp_require_stapling(tls_config);
@@ -278,6 +281,14 @@ process_ssl_options(char *cp)
tls_session_fd) == -1)
errx(1, "failed to set session: %s",
tls_config_error(tls_config));
+ break;
+ case SSL_PROTOCOLS:
+ if (str == NULL)
+ errx(1, "missing protocol name");
+ if (tls_config_parse_protocols(, str) != 0)
+ errx(1, "failed to parse TLS protocols");
+ if (tls_config_set_protocols(tls_config, protocols) !=
0)
+ errx(1, "failed to set TLS protocols");
break;
default:
errx(1, "unknown -S suboption `%s'",
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
