Re: security - preferred way to make check_access_file happy?
> On 2019-02-26, at 02:01 , Solene Rapenne wrote: > [...] > > Use vipw to put 13 * in the password field > [...] Or, FWIW, just: usermod -p '*' user Ross
Re: www/iridium and www/chromium README about unveil
On 2019/02/25 14:28, Theo de Raadt wrote: > >There is another issue here. I'm not sure if it is because me or all > >are experiencing it. > > > >Each run after install, chromium is not able to cd into the designed > >~/Downloads/ > >It looks like I am thrown into ~ and I can't move from there because > >of that error message. > >A good setup for this is run chrome --disable-unveil and set up the > >download directory, then run it normally with unveil and be able to > >use it. > > > >Also a big confusion with iridium is when the downloaded files are not > >accessible / are deleted / are not shown because of some potential > >danger to your computer. Seriously, Internet Explorer style? Didn't > >bother to investigate this, I don't run iridium anymore. It looks to > >me like chromium with some check marks disabled in settings. > > please try a very recent set of packages. robert has been working > on resolving that mess. > Current status for chromium 72.0.3626.109p0 or newer: you can get to ~/Downloads via buttons (as long as it's a directory not a symlink), and you can get to /tmp if you type in the path. This isn't ported to iridium yet.
Re: www/iridium and www/chromium README about unveil
>There is another issue here. I'm not sure if it is because me or all >are experiencing it. > >Each run after install, chromium is not able to cd into the designed >~/Downloads/ >It looks like I am thrown into ~ and I can't move from there because >of that error message. >A good setup for this is run chrome --disable-unveil and set up the >download directory, then run it normally with unveil and be able to >use it. > >Also a big confusion with iridium is when the downloaded files are not >accessible / are deleted / are not shown because of some potential >danger to your computer. Seriously, Internet Explorer style? Didn't >bother to investigate this, I don't run iridium anymore. It looks to >me like chromium with some check marks disabled in settings. please try a very recent set of packages. robert has been working on resolving that mess.
Re: [wip] graphics/tiff: enable more compression formats
On Sun, Feb 24, 2019 at 10:41:15PM +0100, Landry Breuil wrote: > Hi, > > for various gis toolchain wip i have @work, i need to experiment with > webp, lzma & zstd compression in the geotiff container (see the various > COMPRESS options in https://www.gdal.org/frmt_gtiff.html) - and either i > need to make gdal use its internal tiff copy (where all options are > enabled) or enable those options on the systemwide tiff. > > im not pushing for this diff, but i'd like to start a discussion on the > rationale - i looked, and xz/libwebp/zstd build fine on all the archs we > build pkgs on (aarch64, amd64, arm, i386, mips64, mips64el, powerpc, > sparc64) and the options are all enabled by default in upstream libtiff > (development is driven by gdal developers anyway those days). > > of course this would impact wantlib for all graphics/tiff consumers, > which is 186 ports according to sqlports, and require a bulk as 7300 > ports indirectly depend on it according to show-reverse-deps. Disregarde for now, as graphics/libwebp depends on tiff this creates a cyclic dependency. enabling xz & zstd might work though.
Re: NEW: squash-fuse
I'm going to try this port, since I'm building it on a USG it might
take awhile. :-)
thanks
diana
On Mon, Feb 25, 2019 at 12:22 PM Stuart Henderson wrote:
>
> On 2019/02/25 18:55, Sebastian Benoit wrote:
> > squashfuse - Mount SquashFS archives using FUSE
> > https://github.com/vasi/squashfuse/blob/master/README
> >
> > I dont know if i got the WANTLIB right.
> >
> > I also havent tested it, for lack of a squashfs filesystem, but maybe Diana
> > Eichert can try it. ;)
> >
>
> here's a diff on top, bit of cleanup, and enable the dep's - new tgz
> attached.
>
> I haven't changed it here but directory name is probably better as
> squashfuse rather than squash-fuse to match the PKGNAME
>
> diff --git Makefile Makefile
> index 81a19bd..f631117 100644
> --- Makefile
> +++ Makefile
> @@ -2,36 +2,37 @@
>
> COMMENT = squashfs file system through FUSE
>
> -V =0.1.103
> GH_ACCOUNT = vasi
> GH_PROJECT = squashfuse
> -GH_TAGNAME = ${V}
> -DISTNAME = squashfuse-${V}
> +GH_TAGNAME = 0.1.103
> +
> +SHARED_LIBS += fuseprivate 0.0 # 0.0
> +SHARED_LIBS += squashfuse0.0 # 0.0
>
> CATEGORIES = sysutils
>
> # BSD
> PERMIT_PACKAGE_CDROM = Yes
>
> -SHARED_LIBS += fuseprivate 0.0 # 0.0
> -SHARED_LIBS += squashfuse0.0 # 0.0
> +WANTLIB += c fuse lz4 lzma lzo2 pthread z zstd
> +
> +CONFIGURE_STYLE = gnu
>
> -WANTLIB = c fuse pthread z
> +CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
> + LDFLAGS="-L${LOCALBASE}/lib"
>
> -CONFIGURE_STYLE = gnu
> AUTOMAKE_VERSION = 1.16
> AUTOCONF_VERSION = 2.69
> BUILD_DEPENDS =${MODGNU_AUTOCONF_DEPENDS} \
> ${MODGNU_AUTOMAKE_DEPENDS} \
> devel/libtool
>
> -#BUILD_DEPENDS += archivers/lzo2 \
> -# archivers/xz \
> -# archivers/lz4
> +LIB_DEPENDS += archivers/lz4 \
> + archivers/lzo2 \
> + archivers/xz \
> + archivers/zstd
>
> -pre-configure:
> - cd ${WRKSRC} && ${SETENV} AUTOMAKE_VERSION=${AUTOMAKE_VERSION} \
> - AUTOCONF_VERSION=${AUTOCONF_VERSION} \
> - autoreconf -fi
> +do-gen:
> + cd ${WRKSRC} && ${AUTOCONF_ENV} autoreconf -fi
>
> .include
>
--
-
Past hissy-fits are not a predictor of future hissy-fits.
Nick Holland(06 Dec 2005)
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public. - Theodore Roosevelt(1918)
Re: NEW: squash-fuse
On 2019/02/25 18:55, Sebastian Benoit wrote:
> squashfuse - Mount SquashFS archives using FUSE
> https://github.com/vasi/squashfuse/blob/master/README
>
> I dont know if i got the WANTLIB right.
>
> I also havent tested it, for lack of a squashfs filesystem, but maybe Diana
> Eichert can try it. ;)
>
here's a diff on top, bit of cleanup, and enable the dep's - new tgz
attached.
I haven't changed it here but directory name is probably better as
squashfuse rather than squash-fuse to match the PKGNAME
diff --git Makefile Makefile
index 81a19bd..f631117 100644
--- Makefile
+++ Makefile
@@ -2,36 +2,37 @@
COMMENT = squashfs file system through FUSE
-V =0.1.103
GH_ACCOUNT = vasi
GH_PROJECT = squashfuse
-GH_TAGNAME = ${V}
-DISTNAME = squashfuse-${V}
+GH_TAGNAME = 0.1.103
+
+SHARED_LIBS += fuseprivate 0.0 # 0.0
+SHARED_LIBS += squashfuse0.0 # 0.0
CATEGORIES = sysutils
# BSD
PERMIT_PACKAGE_CDROM = Yes
-SHARED_LIBS += fuseprivate 0.0 # 0.0
-SHARED_LIBS += squashfuse0.0 # 0.0
+WANTLIB += c fuse lz4 lzma lzo2 pthread z zstd
+
+CONFIGURE_STYLE = gnu
-WANTLIB = c fuse pthread z
+CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
+ LDFLAGS="-L${LOCALBASE}/lib"
-CONFIGURE_STYLE = gnu
AUTOMAKE_VERSION = 1.16
AUTOCONF_VERSION = 2.69
BUILD_DEPENDS =${MODGNU_AUTOCONF_DEPENDS} \
${MODGNU_AUTOMAKE_DEPENDS} \
devel/libtool
-#BUILD_DEPENDS += archivers/lzo2 \
-# archivers/xz \
-# archivers/lz4
+LIB_DEPENDS += archivers/lz4 \
+ archivers/lzo2 \
+ archivers/xz \
+ archivers/zstd
-pre-configure:
- cd ${WRKSRC} && ${SETENV} AUTOMAKE_VERSION=${AUTOMAKE_VERSION} \
- AUTOCONF_VERSION=${AUTOCONF_VERSION} \
- autoreconf -fi
+do-gen:
+ cd ${WRKSRC} && ${AUTOCONF_ENV} autoreconf -fi
.include
squash-fuse,2.tgz
Description: application/tar-gz
Re: NEW: squash-fuse
On Mon, Feb 25, 2019 at 06:55:35PM +0100, Sebastian Benoit wrote:
> squashfuse - Mount SquashFS archives using FUSE
> https://github.com/vasi/squashfuse/blob/master/README
>
> I dont know if i got the WANTLIB right.
Various libraries are picked up if present, you can en/disable
explicitly at configure time and check WANTLIB with
`port-lib-depends-check' afterwards.
See bsd.port.mk(5) wrt. the `gen' target, it can replace `pre-configure':
do-gen:
cd ${WRKSRC} && env -i ${AUTOCONF_ENV} autoreconf -fi
NEW: squash-fuse
squashfuse - Mount SquashFS archives using FUSE https://github.com/vasi/squashfuse/blob/master/README I dont know if i got the WANTLIB right. I also havent tested it, for lack of a squashfs filesystem, but maybe Diana Eichert can try it. ;) squash-fuse.tgz Description: GNU Unix tar archive
Re: security - preferred way to make check_access_file happy?
On 2019/02/25 18:20, Theo Buehler wrote:
> On Mon, Feb 25, 2019 at 05:14:50PM +, Stuart Henderson wrote:
> > On 2019/02/25 09:13, Adam Thompson wrote:
> > > > Use vipw to put 13 * in the password field
> > > >
> > > > From passwd(5)
> > > > [...]
> > > > authentication, conventionally have 13 asterisks in the password field.
> > >
> > > Thank you! Now that I know what I'm looking for, I can see the relevant
> > > code in security(8), too.
> > >
> > > I wonder if there's a way for ports to do that for me while calling
> > > useradd?
> > > Another rabbit hole to go down.
> > >
> > > Thanks again,
> > > -Adam
> > >
> >
> > It normally does already. Do you have an unusual "password" line in
> > /etc/usermgmt.conf?
>
> I think the user(8) behavior changed in that regard in user.c rev 1.112
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/user/user.c.diff?r1=1.111&r2=1.112
>
> @@ -1130,16 +1082,8 @@
> warnx("Warning: home directory `%s' doesn't exist, and -m was"
> " not specified", home);
> }
> - if (up->u_password != NULL && valid_password_length(up->u_password)) {
> - (void) strlcpy(password, up->u_password, sizeof(password));
> - } else {
> - (void) memset(password, '*', DES_Len);
> - password[DES_Len] = 0;
> - if (up->u_password != NULL) {
> - warnx("Password `%s' is invalid: setting it to `%s'",
> - up->u_password, password);
> - }
> - }
> + (void) strlcpy(password, up->u_password ? up->u_password : "*",
> + sizeof(password));
> cc = snprintf(buf, sizeof(buf), "%s:%s:%u:%u:%s:%lld:%lld:%s:%s:%s\n",
> login_name,
> password,
>
Ah yes - I must have been looking at users from old installed
packages. Now I scroll down further I see them too..
[SECURITY UPDATE] net/mattermost-server
Dear all,
Please find the latest net/mattermost-server update attached.
According to the CHANGELOG,
"Mattermost v5.8.0 contains low to high level security fixes.
Upgrading is highly recommended".
https://docs.mattermost.com/administration/changelog.html
Important port changes:
1. I think renaming mattermost bin to mattermost-server and placing it into
/usr/local/sbin should be reverted.
mattermost binary runs the server, but it also runs CLI interface to manage
the server. In the docs it's just "mattermost", not "mattermost-server".
I think getting closer to the source won't be a problem for anyone.
2. Fixed config/log paths, so mattermost cli works without necessity
of descending into /usr/share/mattermost and specifying -c flag.
3. Mattermost config should be /etc/mattermost/config.json. If mattermost
starts and cannot find config.json, it writes default.json and starts with
defaults from it.
4. Enforce security on /etc/mattermost and /var/log/mattermost dirs
(chmod o=), it can have sensitive information.
Finally, I'd propose renaming net/mattermost-server to net/mattermost
to get rid of unnecessary ambiguity in naming. This change can be seen
as questionable, so I don't include it though it's as easy as adding
PKGNAME = mattermost-${V}.
--
With best regards,
Pavel Korovin
Index: Makefile
===
RCS file: /cvs/ports/net/mattermost-server/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile14 Feb 2019 06:26:03 - 1.9
+++ Makefile25 Feb 2019 16:48:57 -
@@ -2,7 +2,7 @@
COMMENT = open source Slack-alternative
-V =5.7.1
+V =5.8.0
GH_ACCOUNT = mattermost
GH_PROJECT = mattermost-server
GH_TAGNAME = v${V}
@@ -30,19 +30,20 @@ MODGO_LDFLAGS = -X github.com/mattermost
NO_TEST = Yes
pre-configure:
- ${SUBST_CMD} ${WRKDIST}/config/default.json
+ ${SUBST_CMD} ${WRKDIST}/config/default.json
${WRKDIST}/utils/fileutils/fileutils.go \
+ ${WRKDIST}/cmd/mattermost/commands/logs.go
do-build:
cd ${WRKSRC}/cmd/mattermost && \
${MODGO_BUILD_CMD}
do-install:
- ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/mattermost
${PREFIX}/sbin/mattermost-server
- ${INSTALL_DATA_DIR} ${PREFIX}/share/mattermost
- ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/mattermost
- cp ${WRKSRC}/config/default.json ${PREFIX}/share/examples/mattermost
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/mattermost ${PREFIX}/bin/
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/mattermost/
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/mattermost/
+ cp ${WRKSRC}/config/default.json ${PREFIX}/share/examples/mattermost/
.for _d in client fonts i18n templates
- cp -Rp ${WRKDIR}/mattermost/${_d} ${PREFIX}/share/mattermost
+ cp -Rp ${WRKDIR}/mattermost/${_d} ${PREFIX}/share/mattermost/
.endfor
.include
Index: distinfo
===
RCS file: /cvs/ports/net/mattermost-server/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo14 Feb 2019 06:26:03 - 1.8
+++ distinfo25 Feb 2019 16:48:57 -
@@ -1,4 +1,4 @@
-SHA256 (mattermost-5.7.1-linux-amd64.tar.gz) =
CfQGjhLkNUMydhcsGiWwy3TjVGh3h+eBy6emxUZ7q2c=
-SHA256 (mattermost-server-5.7.1.tar.gz) =
y0mtZL11S8xpSPEf91PREkk8TFSGKvZ4+AI+6GEQwZ4=
-SIZE (mattermost-5.7.1-linux-amd64.tar.gz) = 102660133
-SIZE (mattermost-server-5.7.1.tar.gz) = 10293290
+SHA256 (mattermost-5.8.0-linux-amd64.tar.gz) =
+VxDjIEXH2kpwPJDjDWLfhzL00NUays+daX50UsCQs0=
+SHA256 (mattermost-server-5.8.0.tar.gz) =
J9489c3WFNclUeTgU7/pA0Xw4AS/ccYDbFRzasG0i10=
+SIZE (mattermost-5.8.0-linux-amd64.tar.gz) = 98792460
+SIZE (mattermost-server-5.8.0.tar.gz) = 16551687
Index: patches/patch-cmd
Re: security - preferred way to make check_access_file happy?
On 2019-02-25 11:14, Stuart Henderson wrote: On 2019/02/25 09:13, Adam Thompson wrote: > Use vipw to put 13 * in the password field > > From passwd(5) > [...] > authentication, conventionally have 13 asterisks in the password field. Thank you! Now that I know what I'm looking for, I can see the relevant code in security(8), too. I wonder if there's a way for ports to do that for me while calling useradd? Another rabbit hole to go down. Thanks again, -Adam It normally does already. Do you have an unusual "password" line in /etc/usermgmt.conf? Nope. Ugh, although I said ports does this often in my experience, the only system/port I have right now where it's doing it is the RANCID package on that dedicated VM. I have two other VMs where I have manually created single-purpose userids without passwords that also complain (one for RT [not from ports], one for webhosting). So it could just be that package; at least I can't demonstrate any others right now. -Adam
Re: www/iridium and www/chromium README about unveil
On Mon, Feb 25, 2019 at 02:35:04PM +0100, Solene Rapenne wrote:
> > thanks for feedback. I'm unsure about wording, I reworked it a bit from
> > your suggestions.
> >
> >
> > Index: pkg/README
> > ===
> > RCS file: pkg/README
> > diff -N pkg/README
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ pkg/README 12 Feb 2019 18:13:05 -
> > @@ -0,0 +1,27 @@
> > +$OpenBSD: README-main,v 1.2 2018/09/04 12:46:25 espie Exp $
> > +
> > ++---
> > +| Running ${PKGSTEM} on OpenBSD
> > ++---
> > +
> > +Unveil
> > +=
> > +Iridium has been patched to use pledge and unveil, so it can only
> > +display paths allowed in /etc/iridium/unveil.main, this includes
> > +the following paths:
> > +
> > + ~/Documents ~/Downloads ~/Music
> > + ~/Pictures ~/Videos/tmp
> > +
> > +If you need to upload a file, you need to make the file available
> > +in one of those folders.
> > +
> > +When iridium file browser is showing up, it may be displaying an
> > +unauthorized folder which will appear empty, which mean it is not
> > +possible to browse to some other location. One can use the keyboard
> > +shortcut Ctrl+L and type a path in the upper address bar to reach a
> > +whitelisted path.
> > +
> > +If you want your browser to be able to walk through your filesystem,
> > +which is discouraged, unveil can be disabled at runtime by using the
> > +parameter --disable-unveil
I think the allowed paths should be synced with chromium first.
--
Antoine
Re: security - preferred way to make check_access_file happy?
On Mon, Feb 25, 2019 at 05:14:50PM +, Stuart Henderson wrote:
> On 2019/02/25 09:13, Adam Thompson wrote:
> > > Use vipw to put 13 * in the password field
> > >
> > > From passwd(5)
> > > [...]
> > > authentication, conventionally have 13 asterisks in the password field.
> >
> > Thank you! Now that I know what I'm looking for, I can see the relevant
> > code in security(8), too.
> >
> > I wonder if there's a way for ports to do that for me while calling useradd?
> > Another rabbit hole to go down.
> >
> > Thanks again,
> > -Adam
> >
>
> It normally does already. Do you have an unusual "password" line in
> /etc/usermgmt.conf?
I think the user(8) behavior changed in that regard in user.c rev 1.112
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/user/user.c.diff?r1=1.111&r2=1.112
@@ -1130,16 +1082,8 @@
warnx("Warning: home directory `%s' doesn't exist, and -m was"
" not specified", home);
}
- if (up->u_password != NULL && valid_password_length(up->u_password)) {
- (void) strlcpy(password, up->u_password, sizeof(password));
- } else {
- (void) memset(password, '*', DES_Len);
- password[DES_Len] = 0;
- if (up->u_password != NULL) {
- warnx("Password `%s' is invalid: setting it to `%s'",
- up->u_password, password);
- }
- }
+ (void) strlcpy(password, up->u_password ? up->u_password : "*",
+ sizeof(password));
cc = snprintf(buf, sizeof(buf), "%s:%s:%u:%u:%s:%lld:%lld:%s:%s:%s\n",
login_name,
password,
Re: www/iridium and www/chromium README about unveil
There is another issue here. I'm not sure if it is because me or all are experiencing it. Each run after install, chromium is not able to cd into the designed ~/Downloads/ It looks like I am thrown into ~ and I can't move from there because of that error message. A good setup for this is run chrome --disable-unveil and set up the download directory, then run it normally with unveil and be able to use it. Also a big confusion with iridium is when the downloaded files are not accessible / are deleted / are not shown because of some potential danger to your computer. Seriously, Internet Explorer style? Didn't bother to investigate this, I don't run iridium anymore. It looks to me like chromium with some check marks disabled in settings.
Re: security - preferred way to make check_access_file happy?
On 2019/02/25 09:13, Adam Thompson wrote: > > Use vipw to put 13 * in the password field > > > > From passwd(5) > > [...] > > authentication, conventionally have 13 asterisks in the password field. > > Thank you! Now that I know what I'm looking for, I can see the relevant > code in security(8), too. > > I wonder if there's a way for ports to do that for me while calling useradd? > Another rabbit hole to go down. > > Thanks again, > -Adam > It normally does already. Do you have an unusual "password" line in /etc/usermgmt.conf?
Re: security - preferred way to make check_access_file happy?
Use vipw to put 13 * in the password field From passwd(5) [...] authentication, conventionally have 13 asterisks in the password field. Thank you! Now that I know what I'm looking for, I can see the relevant code in security(8), too. I wonder if there's a way for ports to do that for me while calling useradd? Another rabbit hole to go down. Thanks again, -Adam
Re: security - preferred way to make check_access_file happy?
On 2019/02/25 08:50, Adam Thompson wrote: > Hi, > I'm getting daily insecurity (i.e. security(8)) nags about userids that are > off but still have a valid shell and access files. (Specifically, I'm > getting the nag from check_access_files() in /usr/libexec/security.) > > Since ports (at least in my experience) regularly creates userids that will > trigger this warning, what's the "best" way to disable the warning? I'm > reluctant to mess with permissions on directories created by packages, but > maybe that's the best way? > > Otherwise, it looks like I can disable the warning by setting a password on > the userid in question. > > However, that leads to the question: what if I don't *want* a password on > the account, because it's supposed to be a SFTP-only, > public-key-authentication-only account, but still needs to be readable and > needs a valid shell for various cron jobs to be happy? If I'm following the > logic correctly, one of the warnings I'm getting is for ~/.ssh being > readable on a userid with no password - exactly the scenario I just > mentioned. But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? > > The most distasteful option is to hack /usr/libexec/security to ignore > certain userids, but ... it's there for a reason. > > The cleanest example I have right now from ports is _rancid, created by the > rancid package, and triggered by the existence of ~_rancid/.ssh with S_IRUSR > (u+r) permissions. > > Suggestions / advice? > > Thanks, > -Adam > slightly dirty (but reliable) hack: set the password to thirteen *'s instead of just one, so it looks like a DES crypted password instead, like all the users present in the base OS or added by normal pkg_add. of course this makes the /etc/security check not entirely useful, because one could quietly create .ssh/authorized_keys for a home dir for a "ports" uid and security won't pick it up ...
Re: security - preferred way to make check_access_file happy?
On Mon, Feb 25, 2019 at 09:13:33AM -0600, Adam Thompson wrote: > > Use vipw to put 13 * in the password field > > > > From passwd(5) > > [...] > > authentication, conventionally have 13 asterisks in the > > password field. > > Thank you! Now that I know what I'm looking for, I can see the > relevant code in security(8), too. > > I wonder if there's a way for ports to do that for me while > calling useradd? Another rabbit hole to go down. > > Thanks again, > -Adam > all my users installed by packages have 13 * in that second field when I check with "doas vipw"
Re: security - preferred way to make check_access_file happy?
On Mon, Feb 25, 2019 at 08:50:18AM -0600, Adam Thompson wrote: > Hi, > I'm getting daily insecurity (i.e. security(8)) nags about > userids that are off but still have a valid shell and access > files. (Specifically, I'm getting the nag from > check_access_files() in /usr/libexec/security.) > > Since ports (at least in my experience) regularly creates > userids that will trigger this warning, what's the "best" way to > disable the warning? I'm reluctant to mess with permissions on > directories created by packages, but maybe that's the best way? > > Otherwise, it looks like I can disable the warning by setting a > password on the userid in question. > > However, that leads to the question: what if I don't *want* a > password on the account, because it's supposed to be a > SFTP-only, public-key-authentication-only account, but still > needs to be readable and needs a valid shell for various cron > jobs to be happy? If I'm following the logic correctly, one of > the warnings I'm getting is for ~/.ssh being readable on a > userid with no password - exactly the scenario I just mentioned. > But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? > > The most distasteful option is to hack /usr/libexec/security to > ignore certain userids, but ... it's there for a reason. > > The cleanest example I have right now from ports is _rancid, > created by the rancid package, and triggered by the existence of > ~_rancid/.ssh with S_IRUSR (u+r) permissions. > > Suggestions / advice? > > Thanks, > -Adam > Use vipw to put 13 * in the password field >From passwd(5) The password field is the encrypted form of the password. If the password field is empty, no password will be required to gain access to the machine. This is almost invariably a mistake. By convention, accounts that are not intended to be logged in to (e.g. bin, daemon, sshd) only contain a single asterisk in the password field. Note that there is nothing special about ‘*’, it is just one of many characters that cannot occur in a valid encrypted password (see crypt(3)). Similarly, login accounts not allowing password authentication but allowing other authentication methods, for example public key authentication, conventionally have 13 asterisks in the password field. Because master.passwd contains the encrypted user passwords, it should not be readable by anyone without appropriate privileges.
Re: security - preferred way to make check_access_file happy?
Whoops... I'm getting the messages from 3 systems, all running 6.4-STABLE, with no local modifications, under both VMware and Openstack, using openup to keep systems updated. Dmesg available if anyone thinks it's relevant. -Adam On 2019-02-25 08:50, Adam Thompson wrote: Hi, I'm getting daily insecurity (i.e. security(8)) nags about userids that are off but still have a valid shell and access files. (Specifically, I'm getting the nag from check_access_files() in /usr/libexec/security.) Since ports (at least in my experience) regularly creates userids that will trigger this warning, what's the "best" way to disable the warning? I'm reluctant to mess with permissions on directories created by packages, but maybe that's the best way? Otherwise, it looks like I can disable the warning by setting a password on the userid in question. However, that leads to the question: what if I don't *want* a password on the account, because it's supposed to be a SFTP-only, public-key-authentication-only account, but still needs to be readable and needs a valid shell for various cron jobs to be happy? If I'm following the logic correctly, one of the warnings I'm getting is for ~/.ssh being readable on a userid with no password - exactly the scenario I just mentioned. But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? The most distasteful option is to hack /usr/libexec/security to ignore certain userids, but ... it's there for a reason. The cleanest example I have right now from ports is _rancid, created by the rancid package, and triggered by the existence of ~_rancid/.ssh with S_IRUSR (u+r) permissions. Suggestions / advice? Thanks, -Adam
security - preferred way to make check_access_file happy?
Hi, I'm getting daily insecurity (i.e. security(8)) nags about userids that are off but still have a valid shell and access files. (Specifically, I'm getting the nag from check_access_files() in /usr/libexec/security.) Since ports (at least in my experience) regularly creates userids that will trigger this warning, what's the "best" way to disable the warning? I'm reluctant to mess with permissions on directories created by packages, but maybe that's the best way? Otherwise, it looks like I can disable the warning by setting a password on the userid in question. However, that leads to the question: what if I don't *want* a password on the account, because it's supposed to be a SFTP-only, public-key-authentication-only account, but still needs to be readable and needs a valid shell for various cron jobs to be happy? If I'm following the logic correctly, one of the warnings I'm getting is for ~/.ssh being readable on a userid with no password - exactly the scenario I just mentioned. But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? The most distasteful option is to hack /usr/libexec/security to ignore certain userids, but ... it's there for a reason. The cleanest example I have right now from ports is _rancid, created by the rancid package, and triggered by the existence of ~_rancid/.ssh with S_IRUSR (u+r) permissions. Suggestions / advice? Thanks, -Adam
NEW: devel/p5-Locale-Codes
Hi, Locale::Codes will be removed from next Perl version: $ perl -e 'use Locale::Country;' Locale::Codes will be removed from the Perl core distribution in the next major release. Please install it from CPAN. It is being used at /usr/libdata/perl5/Locale/Country.pm, line 22. Attached a port of it. $ cat p5-Locale-Codes/pkg/DESCR Locale-Codes is a distribution containing a set of modules designed to work with sets of codes which uniquely identify something. For example, there are codes associated with different countries, different currencies, different languages, etc. These sets of codes are typically maintained in some standard. Comments ? ok ? Cheers Giovanni p5-Locale-Codes-3.59.tgz Description: application/compressed-tar
Re: www/iridium and www/chromium README about unveil
> thanks for feedback. I'm unsure about wording, I reworked it a bit from
> your suggestions.
>
>
> Index: pkg/README
> ===
> RCS file: pkg/README
> diff -N pkg/README
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ pkg/README12 Feb 2019 18:13:05 -
> @@ -0,0 +1,27 @@
> +$OpenBSD: README-main,v 1.2 2018/09/04 12:46:25 espie Exp $
> +
> ++---
> +| Running ${PKGSTEM} on OpenBSD
> ++---
> +
> +Unveil
> +=
> +Iridium has been patched to use pledge and unveil, so it can only
> +display paths allowed in /etc/iridium/unveil.main, this includes
> +the following paths:
> +
> + ~/Documents ~/Downloads ~/Music
> + ~/Pictures ~/Videos/tmp
> +
> +If you need to upload a file, you need to make the file available
> +in one of those folders.
> +
> +When iridium file browser is showing up, it may be displaying an
> +unauthorized folder which will appear empty, which mean it is not
> +possible to browse to some other location. One can use the keyboard
> +shortcut Ctrl+L and type a path in the upper address bar to reach a
> +whitelisted path.
> +
> +If you want your browser to be able to walk through your filesystem,
> +which is discouraged, unveil can be disabled at runtime by using the
> +parameter --disable-unveil
>
up
Re: gzdoom broken on arm/arm64
On Mon, Feb 25, 2019 at 01:39:31PM +0100, Jeremie Courreges-Anglas wrote: > > See > > http://build-failures.rhaalovely.net/arm/2019-02-07/games/gzdoom.log > http://build-failures.rhaalovely.net/aarch64/2019-02-14/games/gzdoom.log > > # error "[asmjit] armDetectCpuInfo() - Unsupported OS." > > JIT support on arm/arm64 seems only available on Windows and Linux. The > latter uses getauxval(3) which is not easy to emulate. As far as I can > see, the toplevel CMakeLists.txt doesn't provide a way to disable > asmjit. > > ok to mark gzdoom as "NOT_FOR_ARCHS" on the two affected platforms and > save a few minutes for other ports? > > > --- Makefile.~1.2.~ Mon Feb 25 12:42:39 2019 > +++ Makefile Mon Feb 25 13:36:32 2019 > @@ -1,5 +1,8 @@ > # $OpenBSD: Makefile,v 1.2 2019/02/12 18:07:11 solene Exp $ > > +# asmjit only supported on Windows and Linux > +NOT_FOR_ARCHS = arm arm64 > + > COMMENT =OpenGL engine for idTech 1 games like > doom,hexen,heretic... > > V = 3.7.1 > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > ok solene@
textproc/cloc, update / new-perl deprecation warning fix
old:
$ time cloc . | head -5
Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <--
HERE in m/({ <-- HERE |})/ at /usr/local/bin/cloc line 8166.
391 text files.
378 unique files.
48 files ignored.
github.com/AlDanial/cloc v 1.74 T=6.78 s (50.6 files/s, 6859.3 lines/s)
0m07.30s real 0m01.06s user 0m06.19s system
new:
$ time cloc . | head -5
391 text files.
378 unique files.
25 files ignored.
github.com/AlDanial/cloc v 1.80 T=0.60 s (611.0 files/s, 80086.7 lines/s)
0m00.95s real 0m00.77s user 0m00.16s system
ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/cloc/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile24 Dec 2017 18:20:49 - 1.11
+++ Makefile25 Feb 2019 13:01:23 -
@@ -2,12 +2,12 @@
COMMENT= count lines of code
-V= 1.74
+V= 1.80
DISTNAME= cloc-${V}
CATEGORIES=textproc devel
-HOMEPAGE= http://cloc.sourceforge.net/
+HOMEPAGE= https://github.com/AlDanial/cloc
MAINTAINER=Joerg Jung
@@ -19,7 +19,9 @@ MASTER_SITES= https://github.com/AlDani
NO_BUILD= Yes
PKG_ARCH= *
-RUN_DEPENDS= devel/p5-Algorithm-Diff textproc/p5-Regexp-Common
+RUN_DEPENDS= devel/p5-Algorithm-Diff \
+ devel/p5-Parallel-ForkManager \
+ textproc/p5-Regexp-Common
BUILD_DEPENDS+=${RUN_DEPENDS}
FAKE_FLAGS=prefix="${PREFIX}" \
Index: distinfo
===
RCS file: /cvs/ports/textproc/cloc/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo24 Dec 2017 18:20:49 - 1.8
+++ distinfo25 Feb 2019 13:01:23 -
@@ -1,2 +1,2 @@
-SHA256 (cloc-1.74.tar.gz) = VaxCPVdmx0I2cApHg47Wa+pHukLh1ZT92JQHS6PrBWc=
-SIZE (cloc-1.74.tar.gz) = 396192
+SHA256 (cloc-1.80.tar.gz) = CC9TUw7uP57oTsRJ7KWad/8RQlDNfa+VGWeVN7WyHWc=
+SIZE (cloc-1.80.tar.gz) = 453965
gzdoom broken on arm/arm64
See http://build-failures.rhaalovely.net/arm/2019-02-07/games/gzdoom.log http://build-failures.rhaalovely.net/aarch64/2019-02-14/games/gzdoom.log # error "[asmjit] armDetectCpuInfo() - Unsupported OS." JIT support on arm/arm64 seems only available on Windows and Linux. The latter uses getauxval(3) which is not easy to emulate. As far as I can see, the toplevel CMakeLists.txt doesn't provide a way to disable asmjit. ok to mark gzdoom as "NOT_FOR_ARCHS" on the two affected platforms and save a few minutes for other ports? --- Makefile.~1.2.~ Mon Feb 25 12:42:39 2019 +++ MakefileMon Feb 25 13:36:32 2019 @@ -1,5 +1,8 @@ # $OpenBSD: Makefile,v 1.2 2019/02/12 18:07:11 solene Exp $ +# asmjit only supported on Windows and Linux +NOT_FOR_ARCHS =arm arm64 + COMMENT = OpenGL engine for idTech 1 games like doom,hexen,heretic... V =3.7.1 -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [Update] www/p5-HTTP-Headers-Fast : update to 0.21
On 2019/02/25 11:51, Stuart Henderson wrote: > Adding maintainer to CC. Any comments Cesare, and are you still > interested in maintaining this port? Oh, I see... :-) : Host or domain name not found. Name service error for name=plusiagamma.org type=: Host not found It is not OK though - build fails. ===> Configuring for p5-HTTP-Headers-Fast-0.21 Can't locate Module/Build/Tiny.pm in @INC (you may need to install the Module::Build::Tiny module) (@INC contains: /usr/local/libdata/perl5/site_perl/amd64-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd /usr/libdata/perl5 .) at Build.PL line 9. BEGIN failed--compilation aborted at Build.PL line 9. > > On 2019/02/25 06:19, wen heping wrote: > > Hi, ports@ : > > > >Here is an patch to update www/p5-HTTP-Headers-Fast to 0.21. > >It build and passed all tests on my OpenBSD-current amd64 system. > > > >Two ports depends on it: > >1 www/p5-Dancer2 : build and all but 2 tests passed. 2 tests failed but > > not because of > > the update of www/p5-HTTP-Headers-Fast. > > 2 www/p5-Plack :build and all tests passed. > > > >The update is required by the future update of www/p5-Dancer2. > >Current version of p5-Dancers failed 2 tests. With the update of > > www/p5-HTTP-Headers-Fast and p5-Dancer2, > > all tests would pass. > > > >Comments? > > > > Cheers, > > wen > > > Index: Makefile > > === > > RCS file: /cvs/ports/www/p5-HTTP-Headers-Fast/Makefile,v > > retrieving revision 1.4 > > diff -u -p -r1.4 Makefile > > --- Makefile20 Mar 2016 19:57:20 - 1.4 > > +++ Makefile25 Feb 2019 02:44:39 - > > @@ -4,7 +4,7 @@ COMMENT = faster implementation of HTTP > > > > MODULES = cpan > > PKG_ARCH = * > > -DISTNAME = HTTP-Headers-Fast-0.20 > > +DISTNAME = HTTP-Headers-Fast-0.21 > > CATEGORIES = www > > > > MAINTAINER = Cesare Gargano > > Index: distinfo > > === > > RCS file: /cvs/ports/www/p5-HTTP-Headers-Fast/distinfo,v > > retrieving revision 1.2 > > diff -u -p -r1.2 distinfo > > --- distinfo27 Nov 2015 21:45:25 - 1.2 > > +++ distinfo25 Feb 2019 02:44:39 - > > @@ -1,2 +1,2 @@ > > -SHA256 (HTTP-Headers-Fast-0.20.tar.gz) = > > 0vTJckYY508wD8dGSY+1hJaS7wz8SvR/5JnEBjlp5SA= > > -SIZE (HTTP-Headers-Fast-0.20.tar.gz) = 19913 > > +SHA256 (HTTP-Headers-Fast-0.21.tar.gz) = > > Xmjtjj5nUx4dQ8aizf0O4trd8uW5TBomSPOmUApvEtU= > > +SIZE (HTTP-Headers-Fast-0.21.tar.gz) = 19578 >
Re: [Update] www/p5-HTTP-Headers-Fast : update to 0.21
Adding maintainer to CC. Any comments Cesare, and are you still interested in maintaining this port? On 2019/02/25 06:19, wen heping wrote: > Hi, ports@ : > >Here is an patch to update www/p5-HTTP-Headers-Fast to 0.21. >It build and passed all tests on my OpenBSD-current amd64 system. > >Two ports depends on it: >1 www/p5-Dancer2 : build and all but 2 tests passed. 2 tests failed but > not because of > the update of www/p5-HTTP-Headers-Fast. > 2 www/p5-Plack :build and all tests passed. > >The update is required by the future update of www/p5-Dancer2. >Current version of p5-Dancers failed 2 tests. With the update of > www/p5-HTTP-Headers-Fast and p5-Dancer2, > all tests would pass. > >Comments? > > Cheers, > wen > Index: Makefile > === > RCS file: /cvs/ports/www/p5-HTTP-Headers-Fast/Makefile,v > retrieving revision 1.4 > diff -u -p -r1.4 Makefile > --- Makefile 20 Mar 2016 19:57:20 - 1.4 > +++ Makefile 25 Feb 2019 02:44:39 - > @@ -4,7 +4,7 @@ COMMENT = faster implementation of HTTP > > MODULES =cpan > PKG_ARCH = * > -DISTNAME = HTTP-Headers-Fast-0.20 > +DISTNAME = HTTP-Headers-Fast-0.21 > CATEGORIES = www > > MAINTAINER = Cesare Gargano > Index: distinfo > === > RCS file: /cvs/ports/www/p5-HTTP-Headers-Fast/distinfo,v > retrieving revision 1.2 > diff -u -p -r1.2 distinfo > --- distinfo 27 Nov 2015 21:45:25 - 1.2 > +++ distinfo 25 Feb 2019 02:44:39 - > @@ -1,2 +1,2 @@ > -SHA256 (HTTP-Headers-Fast-0.20.tar.gz) = > 0vTJckYY508wD8dGSY+1hJaS7wz8SvR/5JnEBjlp5SA= > -SIZE (HTTP-Headers-Fast-0.20.tar.gz) = 19913 > +SHA256 (HTTP-Headers-Fast-0.21.tar.gz) = > Xmjtjj5nUx4dQ8aizf0O4trd8uW5TBomSPOmUApvEtU= > +SIZE (HTTP-Headers-Fast-0.21.tar.gz) = 19578
update git to 2.21.0
Lots of fixes (nothing critical), performance improvements, etc.
https://github.com/git/git/blob/v2.21.0/Documentation/RelNotes/2.21.0.txt
Tests pass on amd64:
fixed 1
success 19851
failed 0
broken 260
total 20458
OK?
Index: devel/git/Makefile
===
RCS file: /cvs/ports/devel/git/Makefile,v
retrieving revision 1.197
diff -u -p -r1.197 Makefile
--- devel/git/Makefile 26 Jan 2019 11:48:18 - 1.197
+++ devel/git/Makefile 25 Feb 2019 09:17:00 -
@@ -4,7 +4,7 @@ COMMENT-main = GIT - Tree History Storag
COMMENT-svn = GIT - subversion interoperability tools
COMMENT-x11 = GIT - graphical tools
-V =2.20.1
+V =2.21.0
DISTNAME = git-${V}
PKGNAME-main = ${DISTNAME}
PKGNAME-svn = git-svn-${V}
Index: devel/git/distinfo
===
RCS file: /cvs/ports/devel/git/distinfo,v
retrieving revision 1.149
diff -u -p -r1.149 distinfo
--- devel/git/distinfo 16 Dec 2018 13:53:22 - 1.149
+++ devel/git/distinfo 25 Feb 2019 09:17:21 -
@@ -1,4 +1,4 @@
-SHA256 (git-2.20.1.tar.gz) = 7cO8FJW2kXm6Ticul+/5MzSiDeyx2Ntuw8GcFkF3OP0=
-SHA256 (git-manpages-2.20.1.tar.gz) =
6cEjRjq9BeFC3v5EqAYM5umFPf2Mg7JULji33qxObUw=
-SIZE (git-2.20.1.tar.gz) = 7962304
-SIZE (git-manpages-2.20.1.tar.gz) = 713938
+SHA256 (git-2.21.0.tar.gz) = heylHHQE2nXjU+ulh/h/6pSBukHhYiBqb3CtgRgUe+4=
+SHA256 (git-manpages-2.21.0.tar.gz) =
FMduu04x+eVc9TOKBP06E7ztAyPNUXlMz0X8dL0MEIA=
+SIZE (git-2.21.0.tar.gz) = 8289375
+SIZE (git-manpages-2.21.0.tar.gz) = 716556
Index: devel/git/patches/patch-config_mak_uname
===
RCS file: /cvs/ports/devel/git/patches/patch-config_mak_uname,v
retrieving revision 1.7
diff -u -p -r1.7 patch-config_mak_uname
--- devel/git/patches/patch-config_mak_uname13 Sep 2018 05:59:22 -
1.7
+++ devel/git/patches/patch-config_mak_uname25 Feb 2019 09:22:36 -
@@ -5,7 +5,7 @@ OpenBSD wants DIR_HAS_BSD_GROUP_SEMANTIC
Index: config.mak.uname
--- config.mak.uname.orig
+++ config.mak.uname
-@@ -225,6 +225,7 @@ endif
+@@ -226,6 +226,7 @@ endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
Index: devel/git/patches/patch-t_t1450-fsck_sh
===
RCS file: devel/git/patches/patch-t_t1450-fsck_sh
diff -N devel/git/patches/patch-t_t1450-fsck_sh
--- devel/git/patches/patch-t_t1450-fsck_sh 16 Dec 2018 13:53:22 -
1.7
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-t_t1450-fsck_sh,v 1.7 2018/12/16 13:53:22 kn Exp $
-
-Avoid GNU grep syntax
-
-Index: t/t1450-fsck.sh
t/t1450-fsck.sh.orig
-+++ t/t1450-fsck.sh
-@@ -629,7 +629,7 @@ test_expect_success 'fsck --name-objects' '
- remove_object $(git rev-parse julius:caesar.t) &&
- test_must_fail git fsck --name-objects >out &&
- tree=$(git rev-parse --verify julius:) &&
-- egrep "$tree \((refs/heads/master|HEAD)@\{[0-9]*\}:" out
-+ grep -E "$tree \(refs/heads/master|HEAD@{[0-9]*}:" out
- )
- '
-
Index: devel/git/patches/patch-t_test-lib_sh
===
RCS file: /cvs/ports/devel/git/patches/patch-t_test-lib_sh,v
retrieving revision 1.29
diff -u -p -r1.29 patch-t_test-lib_sh
--- devel/git/patches/patch-t_test-lib_sh 16 Dec 2018 13:53:22 -
1.29
+++ devel/git/patches/patch-t_test-lib_sh 25 Feb 2019 09:22:22 -
@@ -6,8 +6,8 @@ wants it badly.
Index: t/test-lib.sh
--- t/test-lib.sh.orig
+++ t/test-lib.sh
-@@ -71,6 +71,11 @@ then
- exit 1
+@@ -294,6 +294,11 @@ then
+ exit $stress_exit
fi
+if [ -n "${TEST_TAR}" ]; then
@@ -17,4 +17,4 @@ Index: t/test-lib.sh
+
# if --tee was passed, write the output not only to the terminal, but
# additionally to the file test-results/$BASENAME.out, too.
- case "$GIT_TEST_TEE_STARTED, $* " in
+ if test "$GIT_TEST_TEE_STARTED" = "done"
Index: devel/git/pkg/PLIST-main
===
RCS file: /cvs/ports/devel/git/pkg/PLIST-main,v
retrieving revision 1.87
diff -u -p -r1.87 PLIST-main
--- devel/git/pkg/PLIST-main26 Jan 2019 11:48:18 - 1.87
+++ devel/git/pkg/PLIST-main25 Feb 2019 09:26:42 -
@@ -123,7 +123,6 @@ libexec/git/git-quiltimport
libexec/git/git-rebase--am
libexec/git/git-rebase--common
@bin libexec/git/git-rebase--interactive
-libexec/git/git-rebase--merge
libexec/git/git-rebase--preserve-merges
@bin libexec/git/git-receive-pack
@bin libexec/git/git-reflog
@@ -417,6 +416,7 @@ share/gitweb/static/gitweb.js
share/locale/bg/LC_MESSAGES/git.mo
share/locale/ca/LC_MESSAGES/git.mo
share/locale/de/LC_MESSAGES/git.mo
+share/locale/el/LC_MESSAGES/git.mo
share/locale/es/LC_MESSAGES/git.
[-stable update] net/tor
This updates net/tor to the newest release on the 0.3.4.11 branch for 6.4-stable. Tested on amd64. Index: Makefile === RCS file: /cvs/ports/net/tor/Makefile,v retrieving revision 1.120.2.1 diff -u -p -r1.120.2.1 Makefile --- Makefile7 Dec 2018 19:14:42 - 1.120.2.1 +++ Makefile25 Feb 2019 10:35:17 - @@ -2,7 +2,7 @@ COMMENT= anonymity service using onion routing -DISTNAME= tor-0.3.4.9 +DISTNAME= tor-0.3.4.11 CATEGORIES=net HOMEPAGE= https://www.torproject.org/ Index: distinfo === RCS file: /cvs/ports/net/tor/distinfo,v retrieving revision 1.98.2.1 diff -u -p -r1.98.2.1 distinfo --- distinfo7 Dec 2018 19:14:42 - 1.98.2.1 +++ distinfo25 Feb 2019 10:35:17 - @@ -1,2 +1,2 @@ -SHA256 (tor-0.3.4.9.tar.gz) = GhcQgfArmm/54owImN77dnDlu7O9vK3fz05DBK7dFko= -SIZE (tor-0.3.4.9.tar.gz) = 6695931 +SHA256 (tor-0.3.4.11.tar.gz) = WMZdx3KPv5LjbC2V8fLMm4K25UZtWhnJUkoXb9AUhBI= +SIZE (tor-0.3.4.11.tar.gz) = 6804196 Index: patches/patch-configure_ac === RCS file: /cvs/ports/net/tor/patches/patch-configure_ac,v retrieving revision 1.6 diff -u -p -r1.6 patch-configure_ac --- patches/patch-configure_ac 11 Sep 2018 12:17:23 - 1.6 +++ patches/patch-configure_ac 25 Feb 2019 10:35:17 - @@ -3,7 +3,7 @@ disable -fasynchronous-unwind-tables as Index: configure.ac --- configure.ac.orig +++ configure.ac -@@ -1270,13 +1270,6 @@ fi +@@ -1271,13 +1271,6 @@ fi CFLAGS="$saved_CFLAGS" AC_SUBST(F_OMIT_FRAME_POINTER)
arm bulk build report
bulk build on armv7-0.ports.openbsd.org started on Thu Feb 7 02:42:05 MST 2019 finished at Mon Feb 25 03:15:21 MST 2019 lasted 18D17h33m done with kern.version=OpenBSD 6.4-current (GENERIC) #0: Thu Feb 7 13:31:37 MST 2019 built packages:8666 Feb 7:165 Feb 8:206 Feb 9:166 Feb 10:99 Feb 11:108 Feb 12:148 Feb 13:56 Feb 14:55 Feb 15:251 Feb 16:162 Feb 17:67 Feb 18:154 Feb 19:625 Feb 20:338 Feb 21:796 Feb 22:2202 Feb 23:2487 Feb 25:580 critical path missing pkgs: http://build-failures.rhaalovely.net/arm/2019-02-07/summary.log build failures: 56 http://build-failures.rhaalovely.net/arm/2019-02-07/audio/chromaprint.log http://build-failures.rhaalovely.net/arm/2019-02-07/audio/solfege.log http://build-failures.rhaalovely.net/arm/2019-02-07/comms/lcdproc.log http://build-failures.rhaalovely.net/arm/2019-02-07/databases/xapian-bindings,-main.log http://build-failures.rhaalovely.net/arm/2019-02-07/devel/liboil.log http://build-failures.rhaalovely.net/arm/2019-02-07/devel/llvm,-lldb.log http://build-failures.rhaalovely.net/arm/2019-02-07/devel/openmpi.log http://build-failures.rhaalovely.net/arm/2019-02-07/devel/spyder/spyder,python3.log http://build-failures.rhaalovely.net/arm/2019-02-07/devel/srecord.log http://build-failures.rhaalovely.net/arm/2019-02-07/emulators/dgen-sdl.log http://build-failures.rhaalovely.net/arm/2019-02-07/emulators/dynamips.log http://build-failures.rhaalovely.net/arm/2019-02-07/emulators/ppsspp.log http://build-failures.rhaalovely.net/arm/2019-02-07/emulators/vbam.log http://build-failures.rhaalovely.net/arm/2019-02-07/emulators/vice.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/barony.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/dungeon-crawl.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/fifengine.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/frozen-bubble,-main.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/gzdoom.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/hyperrogue.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/spacehulk.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/stone-soup.log http://build-failures.rhaalovely.net/arm/2019-02-07/games/vacuum.log http://build-failures.rhaalovely.net/arm/2019-02-07/graphics/ImageMagick.log http://build-failures.rhaalovely.net/arm/2019-02-07/graphics/freeimage.log http://build-failures.rhaalovely.net/arm/2019-02-07/graphics/libmpeg2.log http://build-failures.rhaalovely.net/arm/2019-02-07/graphics/ufraw.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/STk.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/erlang/21.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/mruby.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/parrot.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/pfe.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/racket-minimal,no_jit.log http://build-failures.rhaalovely.net/arm/2019-02-07/lang/swi-prolog.log http://build-failures.rhaalovely.net/arm/2019-02-07/mail/bogofilter,db4.log http://build-failures.rhaalovely.net/arm/2019-02-07/mail/courier-unicode.log http://build-failures.rhaalovely.net/arm/2019-02-07/math/dieharder.log http://build-failures.rhaalovely.net/arm/2019-02-07/math/mathomatic.log http://build-failures.rhaalovely.net/arm/2019-02-07/math/mlpack,-main.log http://build-failures.rhaalovely.net/arm/2019-02-07/math/netcdf.log http://build-failures.rhaalovely.net/arm/2019-02-07/math/plplot,-c++.log http://build-failures.rhaalovely.net/arm/2019-02-07/math/z3.log http://build-failures.rhaalovely.net/arm/2019-02-07/misc/openbabel.log http://build-failures.rhaalovely.net/arm/2019-02-07/multimedia/gstreamer-0.10/plugins-ffmpeg.log http://build-failures.rhaalovely.net/arm/2019-02-07/multimedia/gstreamer1/plugins-libav.log http://build-failures.rhaalovely.net/arm/2019-02-07/net/hexchat.log http://build-failures.rhaalovely.net/arm/2019-02-07/net/utox.log http://build-failures.rhaalovely.net/arm/2019-02-07/print/foo2zjs.log http://build-failures.rhaalovely.net/arm/2019-02-07/security/libnipper.log http://build-failures.rhaalovely.net/arm/2019-02-07/www/kwebapp.log http://build-failures.rhaalovely.net/arm/2019-02-07/www/ruby-passenger,ruby26.log http://build-failures.rhaalovely.net/arm/2019-02-07/www/webkitgtk4.log http://build-failures.rhaalovely.net/arm/2019-02-07/x11/afterstep.log http://build-failures.rhaalovely.net/arm/2019-02-07/x11/e17/evas.log http://build-failures.rhaalovely.net/arm/2019-02-07/x11/gnustep/libobjc2.log http://build-failures.rhaalovely.net/arm/2019-02-07/x11/qt4.log
[UPDATE] security/yara
Hi,
this is the diff to update Yara to latest release.
Ok?
Cheers,
Remi.
Index: Makefile.inc
===
RCS file: /cvs/ports/security/yara/Makefile.inc,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 Makefile.inc
--- Makefile.inc 17 Aug 2018 07:49:58 - 1.10
+++ Makefile.inc 25 Feb 2019 09:34:25 -
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile.inc,v 1.10 2018/08/17 07:49:58 rpointel Exp $
-VERSION ?= 3.8.1
+VERSION ?= 3.9.0
CATEGORIES = security
Index: main/distinfo
===
RCS file: /cvs/ports/security/yara/main/distinfo,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 distinfo
--- main/distinfo 17 Aug 2018 07:49:58 - 1.10
+++ main/distinfo 25 Feb 2019 09:34:25 -
@@ -1,2 +1,2 @@
-SHA256 (yara-3.8.1.tar.gz) = KDUncRJpNU08YOJwX390sfdp0tNd26j3+c6X0P1csco=
-SIZE (yara-3.8.1.tar.gz) = 715968
+SHA256 (yara-3.9.0.tar.gz) = 6+f6sKutuQRJpir70k4Zbhixd+/nH/2L8i35XFOG9k0=
+SIZE (yara-3.9.0.tar.gz) = 749159
Index: main/pkg/PLIST
===
RCS file: /cvs/ports/security/yara/main/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 PLIST
--- main/pkg/PLIST 16 Aug 2018 09:58:47 - 1.4
+++ main/pkg/PLIST 25 Feb 2019 09:34:25 -
@@ -26,6 +26,7 @@ include/yara/rules.h
include/yara/scan.h
include/yara/scanner.h
include/yara/sizedstr.h
+include/yara/stack.h
include/yara/stopwatch.h
include/yara/stream.h
include/yara/strutils.h
Index: python/Makefile
===
RCS file: /cvs/ports/security/yara/python/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- python/Makefile 16 Aug 2018 09:58:47 - 1.5
+++ python/Makefile 25 Feb 2019 09:34:25 -
@@ -24,7 +24,7 @@ pre-configure:
BUILD_DEPENDS = security/yara/main>=${VERSION}
RUN_DEPENDS = security/yara/main>=${VERSION}
-TEST_DEPENDS = security/yara/python
+TEST_DEPENDS = security/yara/python${MODPY_FLAVOR}=${VERSION}
do-test:
cd ${WRKSRC} && ${MODPY_BIN} ./tests.py
Index: python/distinfo
===
RCS file: /cvs/ports/security/yara/python/distinfo,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 distinfo
--- python/distinfo 17 Aug 2018 07:49:58 - 1.9
+++ python/distinfo 25 Feb 2019 09:34:25 -
@@ -1,2 +1,2 @@
-SHA256 (yara-python-3.8.1.tar.gz) = CCudK4y05MTdILF8sEvaFVWj3Mq4IHlHNI7PNiXYBgk=
-SIZE (yara-python-3.8.1.tar.gz) = 31526
+SHA256 (yara-python-3.9.0.tar.gz) = X29ZmqAhaWbUfC+q79FBikL8qwRiwHKYw/pKgoBd2PU=
+SIZE (yara-python-3.9.0.tar.gz) = 31624
