Re: lang/hugs (was: 'avoid W|X mappings in libffi' - MARC)

2016-05-24 Thread David Coppa
On Tue, May 24, 2016 at 8:57 PM, Matthias Kilian  wrote:

> IIRC, I once wrote that the ports tree isn't a software museum, so
> instead of trying to fix it, i'd just cimpletely remove it from the
> tree, and maybe other ancient haskell implementations (yes, I mean
> you, nhc98!).
>
> I know that I tried to preserve that old shit a year ago (or even
> less), but it's just in the way and no longer maintained upstream.

bye bye hugs.

ok with me for the removal.



Re: lang/hugs (was: 'avoid W|X mappings in libffi' - MARC)

2016-05-24 Thread Karel Gardas
On Tue, May 24, 2016 at 8:57 PM, Matthias Kilian  wrote:
> IIRC, I once wrote that the ports tree isn't a software museum, so
> instead of trying to fix it, i'd just cimpletely remove it from the
> tree, and maybe other ancient haskell implementations (yes, I mean
> you, nhc98!).

Agree, better concentrate on GHC these days and not waste energy on
museum stuff which may be run on museum OpenBSD anyway...



Re: [new] devel/cargo

2016-05-24 Thread Theo de Raadt
> > "Unlicense" -> "Unlicensed"
> 
> It is "unlicense" - http://unlicense.org/ - it's a bit of a funny
> one this, I'm not sure you can actually release something to the
> public domain and then try and use a copyright-like warranty
> disclaimer..anyway the intent is very clear.

Any verbiage after "public domain" is purely advisory.  So judge --
either it has absolutely no impact and can be ignored, or the text is
dangerous.  I cannot decide.

I love the misuse of the word detriment.  Let me translate it that
part of it:

"We make this dedication for the benefit of the public at large
and to harm our heirs and successors."

Awesome!




Re: [new] devel/cargo

2016-05-24 Thread Stuart Henderson
On 2016/05/24 19:39, Edd Barrett wrote:
> > -sysconfdir=${LOCALBASE}/share/examples/cargo
> 
> Usually syconfdir is /etc, and you use @example in the PLIST to make an
> example. This also means the user can edit the config file without
> upsetting pkg_delete.

This is a bit different though, it's just for the bash-completion
file, and doesn't need @sample'ing. But it would be better to install
it here:

/usr/local/share/bash-completion/completions/

We don't have any infrastructure for loading these completion
scripts automatically, but this is where other packages are
installing them, so it makes sense to follow suit.

> "licence" -> "license"? (although apparently both are correct. I guess
> choose one and stick with it).

"to license" is the verb, "a licence" is the noun.
They work the same way as "advise" and "advice" (which are
often easier to remember because in that case, the sound differs).

> "Unlicense" -> "Unlicensed"

It is "unlicense" - http://unlicense.org/ - it's a bit of a funny
one this, I'm not sure you can actually release something to the
public domain and then try and use a copyright-like warranty
disclaimer..anyway the intent is very clear.




Re: archivers/p7zip: patches for CVE-2016-2334 and CVE-2016-2335

2016-05-24 Thread Stuart Henderson
On 2016/05/23 22:03, Josh Grosse wrote:
> CVE-2016-2334 and CVE-2016-2335 affect 7zip, with code shared
> in p7zip that is installed in /usr/local/lib/p7zip/7z.so.
> 
> Upstream has not yet applied these fixes to code shared with
> 7zip.
> 
> Attached are -current, 5.9, and 5.8 patches.

I don't have time to handle committing this atm, could somebody take
care of it please? OK with me.


> Index: Makefile
> ===
> RCS file: /systems/cvs/ports/archivers/p7zip/Makefile,v
> retrieving revision 1.34
> diff -u -p -r1.34 Makefile
> --- Makefile  12 Apr 2016 23:13:22 -  1.34
> +++ Makefile  24 May 2016 00:31:06 -
> @@ -7,7 +7,7 @@ V=15.14.1
>  DISTNAME=p7zip_${V}_src_all
>  PKGNAME= p7zip-${V}
>  PKGNAME-main=p7zip-${V}
> -REVISION-main=   0
> +REVISION-main=   1
>  PKGNAME-rar= p7zip-rar-${V}
>  CATEGORIES=  archivers
>  
> Index: patches/patch-CPP_7zip_Archive_HfsHandler_cpp
> ===
> RCS file: patches/patch-CPP_7zip_Archive_HfsHandler_cpp
> diff -N patches/patch-CPP_7zip_Archive_HfsHandler_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-CPP_7zip_Archive_HfsHandler_cpp 24 May 2016 00:38:41 
> -
> @@ -0,0 +1,26 @@
> +$OpenBSD$
> +
> +CVE-2016-2334
> +
> +--- CPP/7zip/Archive/HfsHandler.cpp.orig Fri Jun 19 06:52:08 2015
>  CPP/7zip/Archive/HfsHandler.cpp  Mon May 23 20:37:42 2016
> +@@ -987,7 +987,9 @@ HRESULT CDatabase::LoadCatalog(const CFork , cons
> +   item.GroupID = Get32(r + 0x24);
> +   item.AdminFlags = r[0x28];
> +   item.OwnerFlags = r[0x29];
> ++  */
> +   item.FileMode = Get16(r + 0x2A);
> ++  /*
> +   item.special.iNodeNum = Get16(r + 0x2C); // or .linkCount
> +   item.FileType = Get32(r + 0x30);
> +   item.FileCreator = Get32(r + 0x34);
> +@@ -1571,6 +1573,9 @@ HRESULT CHandler::ExtractZlibFile(
> +   blockSize = (UInt32)rem;
> + 
> + UInt32 size = GetUi32(tableBuf + i * 8 + 4);
> ++
> ++if (size > buf.Size() || size > kCompressionBlockSize + 1)
> ++return S_FALSE;
> + 
> + RINOK(ReadStream_FALSE(inStream, buf, size));
> + 
> Index: patches/patch-CPP_7zip_Archive_Udf_UdfIn_cpp
> ===
> RCS file: patches/patch-CPP_7zip_Archive_Udf_UdfIn_cpp
> diff -N patches/patch-CPP_7zip_Archive_Udf_UdfIn_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-CPP_7zip_Archive_Udf_UdfIn_cpp  24 May 2016 00:38:25 
> -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +
> +CVE-2016-2335
> +
> +--- CPP/7zip/Archive/Udf/UdfIn.cpp.orig  Fri Nov 20 15:40:08 2015
>  CPP/7zip/Archive/Udf/UdfIn.cpp   Mon May 23 20:37:46 2016
> +@@ -389,7 +389,11 @@ HRESULT CInArchive::ReadFileItem(int volIndex, int fsI
> + return S_FALSE;
> +   CFile  = Files.Back();
> +   const CLogVol  = LogVols[volIndex];
> +-  CPartition  = 
> Partitions[vol.PartitionMaps[lad.Location.PartitionRef].PartitionIndex];
> ++  unsigned partitionRef = lad.Location.PartitionRef;
> ++
> ++  if (partitionRef >= vol.PartitionMaps.Size())
> ++return S_FALSE;
> ++  CPartition  = 
> Partitions[vol.PartitionMaps[partitionRef].PartitionIndex];
> + 
> +   UInt32 key = lad.Location.Pos;
> +   UInt32 value;

> Index: Makefile
> ===
> RCS file: /systems/cvs/ports/archivers/p7zip/Makefile,v
> retrieving revision 1.31
> diff -u -p -r1.31 Makefile
> --- Makefile  4 Feb 2016 10:38:26 -   1.31
> +++ Makefile  24 May 2016 00:46:00 -
> @@ -6,7 +6,7 @@ COMMENT-main= file archiver with high co
>  COMMENT-rar= rar modules for p7zip
>  
>  V=   15.09
> -REVISION=4
> +REVISION=5
>  DISTNAME=p7zip_${V}_src_all
>  PKGNAME= p7zip-${V}
>  PKGNAME-main=p7zip-${V}
> Index: patches/patch-CPP_7zip_Archive_HfsHandler_cpp
> ===
> RCS file: patches/patch-CPP_7zip_Archive_HfsHandler_cpp
> diff -N patches/patch-CPP_7zip_Archive_HfsHandler_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-CPP_7zip_Archive_HfsHandler_cpp 24 May 2016 00:44:39 
> -
> @@ -0,0 +1,26 @@
> +$OpenBSD$
> +
> +CVE-2016-2334
> +
> +--- CPP/7zip/Archive/HfsHandler.cpp.orig Fri Jun 19 06:52:08 2015
>  CPP/7zip/Archive/HfsHandler.cpp  Mon May 23 20:37:42 2016
> +@@ -987,7 +987,9 @@ HRESULT CDatabase::LoadCatalog(const CFork , cons
> +   item.GroupID = Get32(r + 0x24);
> +   item.AdminFlags = r[0x28];
> +   item.OwnerFlags = r[0x29];
> ++  */
> +   item.FileMode = Get16(r + 0x2A);
> ++  /*
> +   item.special.iNodeNum = Get16(r + 0x2C); // or .linkCount
> +   item.FileType = Get32(r + 0x30);
> +   item.FileCreator = Get32(r + 0x34);
> +@@ -1571,6 +1573,9 @@ HRESULT CHandler::ExtractZlibFile(
> +   blockSize = (UInt32)rem;
> + 
> + UInt32 size = 

lang/hugs (was: 'avoid W|X mappings in libffi' - MARC)

2016-05-24 Thread Matthias Kilian
On Tue, May 24, 2016 at 11:51:08AM +0100, Stuart Henderson wrote:
> I've collected the known problems so far at
> https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing

Regarding lang/hugs, there's this masterpiece in src/builtin.c:

/*
 * Allocate len bytes which are readable, writable, and executable.
 *
 * ToDo: If this turns out to be a performance bottleneck, one could
 * e.g. cache the last VirtualProtect/mprotect-ed region and do
 * nothing in case of a cache hit.
 */
static void* local mallocBytesRWX(int len) {
void *addr = (void *)malloc(len);
#if defined(i386_HOST_ARCH) && defined(_WIN32)
/* This could be necessary for processors which distinguish between
   READ and EXECUTE memory accesses, e.g. Itaniums. */
DWORD dwOldProtect = 0;
if (VirtualProtect(addr, len, PAGE_EXECUTE_READWRITE, ) == 0) {
ERRMSG(0) "mallocBytesRWX: failed to protect 0x%p\n", addr
EEND;
}
#elif defined(openbsd_HOST_OS) || defined(linux_HOST_OS)
/* malloced memory isn't executable by default on OpenBSD */
uintptr_t pageSize = sysconf(_SC_PAGESIZE);
uintptr_t mask = ~(pageSize - 1);
uintptr_t startOfFirstPage = ((uintptr_t)addr  ) & mask;
uintptr_t startOfLastPage  = ((uintptr_t)addr + len - 1) & mask;
uintptr_t size = startOfLastPage - startOfFirstPage + pageSize;
if (mprotect((void*)startOfFirstPage, 
(size_t)size, PROT_EXEC | PROT_READ | PROT_WRITE) != 0) 
{
ERRMSG(0) "mallocBytesRWX: failed to protect 0x%p\n", addr
EEND;
}
#endif
return addr;
}

IIRC, I once wrote that the ports tree isn't a software museum, so
instead of trying to fix it, i'd just cimpletely remove it from the
tree, and maybe other ancient haskell implementations (yes, I mean
you, nhc98!).

I know that I tried to preserve that old shit a year ago (or even
less), but it's just in the way and no longer maintained upstream.

Ciao,
Kili



Re: [new] devel/cargo

2016-05-24 Thread Edd Barrett
Hi Sebastien,

Thanks for your work on this. Here's some low hanging fruit.

On Fri, May 20, 2016 at 05:51:54AM +0200, Sebastien Marie wrote:
> Note it requires the pending lang/rust port update.

Which version? BUILD_DEPENDS says it needs lang/rust>=1.8. Or do you
mean it needs your LOCALBASE tweak? If so, the BUILD_DEPEND will need a
bump.

> -sysconfdir=${LOCALBASE}/share/examples/cargo

Usually syconfdir is /etc, and you use @example in the PLIST to make an
example. This also means the user can edit the config file without
upsetting pkg_delete.

> DISTFILES +=cargo-bootstrap-${BOOTSTRAP_VERSION}.tar.gz:1

It would be nice to have a target that can make the bootstrap tarball
automatically, like, for example, the lang/pypy does. Is that possible?

And some boring nitpicking:

"cartes.io" -> "crates.io"?

"the package doesn't contains it" -> "the package doesn't *contain* it"

"licencied" -> "licensed"

"licence" -> "license"? (although apparently both are correct. I guess
choose one and stick with it).

"Unlicense" -> "Unlicensed"

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk



Re: avoid W|X mappings in libffi

2016-05-24 Thread Sebastian Reitenbach

On Monday, May 23, 2016 21:22 CEST, Jeremie Courreges-Anglas  
wrote:

> Jeremie Courreges-Anglas  writes:
>
> > Theo de Raadt  writes:
> >
> >>> IIUC they would differ on OSes where libffi can't get a single mapping
> >>> with both W and X access.  On those OSes libffi uses a workaround, two
> >>> mappings are allocated one with RW, the other with RX.  While we want to
> >>> disable RWX on OpenBSD as an end goal, I don't think we want to let
> >>> libffi use this hack, 'cause it it basically the same as RWX.
> >>
> >> Yes we do.
> >>
> >> In general, shadow mappings are probably less attackable on a case
> >> to case basis.  Pure RWX mappings are worse.
> >>
> >> The roadmap is to remove as much RWX as possible.  If we can split
> >> some RWX uses off into shadow mappings, that is progress.  At least
> >> code using shadow mappings is half-ready for using mprotect correctly.
> >
> > Then the diff for src/closures.c should be different: it should ensure
> > that libffi uses dlmmap_locked().
>
> On amd64, but the diff should be MI:
>
> === libffi Summary ===
>
> # of expected passes1867
> # of unexpected failures3

patch below at least seems to make the configure test of gnustep-base
happy. Going to rebuild everything with it, and run some applications.

Sebastian

>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/libffi/Makefile,v
> retrieving revision 1.34
> diff -u -p -r1.34 Makefile
> --- Makefile  23 Mar 2016 22:50:29 -  1.34
> +++ Makefile  23 May 2016 18:38:58 -
> @@ -3,7 +3,7 @@
>  COMMENT= Foreign Function Interface
>
>  DISTNAME=libffi-3.2.1
> -REVISION=1
> +REVISION=2
>  SHARED_LIBS +=  ffi  1.2  # .6.4
>  CATEGORIES=  devel
>
> Index: patches/patch-src_closures_c
> ===
> RCS file: patches/patch-src_closures_c
> diff -N patches/patch-src_closures_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_closures_c  23 May 2016 18:38:58 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +--- src/closures.c.orig  Mon May 23 20:34:13 2016
>  src/closures.c   Mon May 23 20:35:56 2016
> +@@ -525,6 +525,7 @@ dlmmap (void *start, size_t length, int prot,
> +   printf ("mapping in %zi\n", length);
> + #endif
> +
> ++#if 0
> +   if (execfd == -1 && is_emutramp_enabled ())
> + {
> +   ptr = mmap (start, length, prot & ~PROT_EXEC, flags, fd, offset);
> +@@ -543,6 +544,7 @@ dlmmap (void *start, size_t length, int prot,
> +  with ((prot & ~PROT_WRITE) | PROT_EXEC) and mremap with
> +  MREMAP_DUP and prot at this point.  */
> + }
> ++#endif
> +
> +   if (execsize == 0 || execfd == -1)
> + {
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE








CVS: cvs.openbsd.org: ports

2016-05-24 Thread Edd Barrett
CVSROOT:/cvs
Module name:ports
Changes by: e...@cvs.openbsd.org2016/05/24 12:01:36

Modified files:
www/py-frozen-flask: Makefile 

Log message:
www/py-frozen-flask: fix build warnings if package not already installed.

Spotted and OK shadchin@. Thanks.



Re: 'avoid W|X mappings in libffi' - MARC

2016-05-24 Thread Kenneth Westerback
Aha. Google says obxj are files emitted by obc? So perhaps that row
just has lang/obc in the wrong column. :-)

 Ken


On 24 May 2016 at 07:05, Kenneth Westerback  wrote:
> What's 'obxj' that your spreadsheet says processes lang/obc?
>
> make search key=obxj
>
> doesn't show anything.
>
> Just curious as lang/obc popped out at me due to my ocaml update work. :-)
>
>  Ken
>
>
> On 24 May 2016 at 06:51, Stuart Henderson  wrote:
>> I've collected the known problems so far at
>> https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing
>>



Re: 'avoid W|X mappings in libffi' - MARC

2016-05-24 Thread Kenneth Westerback
What's 'obxj' that your spreadsheet says processes lang/obc?

make search key=obxj

doesn't show anything.

Just curious as lang/obc popped out at me due to my ocaml update work. :-)

 Ken


On 24 May 2016 at 06:51, Stuart Henderson  wrote:
> I've collected the known problems so far at
> https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing
>



Re: 'avoid W|X mappings in libffi' - MARC

2016-05-24 Thread Stuart Henderson
I've collected the known problems so far at
https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing



CVS: cvs.openbsd.org: ports

2016-05-24 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/05/24 03:57:50

Modified files:
lang/python/2.7: Makefile 
lang/python/2.7/patches: patch-Lib_test_regrtest_py 
 patch-Lib_test_test_tempfile_py 

Log message:
Handle OpenBSD 6.x in Python 2.7 tests. Python 3.x's tests
are done in a different way and don't need this.  OK rpointel@



CVS: cvs.openbsd.org: ports

2016-05-24 Thread David Coppa
CVSROOT:/cvs
Module name:ports
Changes by: dco...@cvs.openbsd.org  2016/05/24 03:13:14

Modified files:
audio/umurmur  : Makefile 
audio/umurmur/patches: patch-src_server_c 
   patch-src_ssli_openssl_c 

Log message:
Fix size of value passed to setsockopt
(git commit d723b45fc42e04b9179ba29c65efc9484ec2924c)

Upgrade TLS suites for OpenSSL
(part of git commit c72ebd29f239793218f2248c3f8b48a7b3e0a541)



CVS: cvs.openbsd.org: ports

2016-05-24 Thread David Coppa
CVSROOT:/cvs
Module name:ports
Changes by: dco...@cvs.openbsd.org  2016/05/24 02:07:58

Modified files:
audio/openal   : Makefile 
Added files:
audio/openal/patches: patch-Alc_mixer_sse_c 

Log message:
Avoid an underflow in the SSE mixers if BufferSize is less than 4
(upstream git commit 564a1822595e287cf808ea63a03d96719e3cc7b4)

Fix a crash with games/ioquake3.
Reported and fix tested by Ryan Freeman.



CVS: cvs.openbsd.org: ports

2016-05-24 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2016/05/24 01:54:16

Modified files:
multimedia/libbluray: Makefile distinfo 
multimedia/libbluray/patches: patch-Makefile_in 

Log message:
Update to libbluray-0.9.3.

from Brad, maintainer timeout



CVS: cvs.openbsd.org: ports

2016-05-24 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2016/05/24 01:53:23

Modified files:
devel/llvm : Makefile 
devel/llvm/patches: patch-tools_clang_lib_Driver_Tools_cpp 

Log message:
Select proper SPARCv9 variant for the assembler.

from Brad (maintainer)