Re: License and adopting software

[blubee blubeeme]

On Tue, Dec 12, 2017 at 6:09 AM, Greg 'groggy' Lehey 
wrote:

> [format recovered]
>
> On Sunday, 10 December 2017 at 23:31:33 -0800, Chris H wrote:
> > On Mon, 11 Dec 2017 12:24:53 +0800 "blubee blubeeme" <
> gurenc...@gmail.com> said
> >> On Mon, Dec 11, 2017 at 12:21 PM, Jonathan Chen 
> wrote:
> >>> On 11 December 2017 at 17:17, blubee blubeeme 
> wrote:
>  I like some old software that's <= GPL2 but it seems like the original
>  developer is not and have not done any work on the software sine mid
>  2000.
> 
>  I'd like to pick up the project, fix bugs BUT i'd like to migrate
>  from GPL to BSD license.
> 
>  How does one go about doing that? I have seen the GPL code but it
>  could be re-written how would that affect me re-writing the code
>  with a new copy center license?
> >>>
> >>> You basically have to get the original author to reassign copyright to
> >>> you; after which you can do whatever you like to it. If you're basing
> >>> your new work on the original work, you have to respect the LICENCE
> >>> that it came with.
> >
> > It's also worth noting; you can dual-license it. That is:
> > their code == their license
> > your code (additions) == your license
>
> No, you can't.  Read the conditions of the GPL license.  If you add
> code to a GPL product, the additions become subject to the GPL.
>
> Greg
> --
> Sent from my desktop computer.
> Finger g...@freebsd.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA
>

I remember reading the history of FreeBSD and in the early days when parts
of what eventually became FreeBSD was re-written. They obviously seen the
prior closed source ATT source code and "re-wrote" it giving it a BSD
license.

It would be cool to hear how they were able to go about it.
Anyone been through the process care to share their experience?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: What is the preferred MASTER_SITES for python port?

[Kubilay Kocak]

On 12/12/2017 1:28 am, Sergey Akhmatov wrote:
> 
> I've looked for the answer in Porters Handbook and at
> https://wiki.freebsd.org/Python/PortsPolicy but haven't found it.

Python Policy wiki page has been updated:

https://wiki.freebsd.org/Python/PortsPolicy#MASTER_SITES

Thank you for the question and report :)

./koobs
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: What is the preferred MASTER_SITES for python port?

[Kubilay Kocak]

On 12/12/2017 1:28 am, Sergey Akhmatov wrote:
> Hello.
> 
> Suppose I want to port some python package that exists in the Python
> Package Index (PyPI) and has it's source code available on some official
> website or github.
> 
> Is there any policy or recommended practice for choosing MASTER_SITES?
> Should I use "USE_GITHUB=yes" or "MASTER_SITES= CHEESESHOP" for such
> package?
> 
> I've looked for the answer in Porters Handbook and at
> https://wiki.freebsd.org/Python/PortsPolicy but haven't found it.
> 
> Thank you.
> 

Hi Sergey:

Use CHEESESHOP by default unless there is a compelling (temporary) case
not to.

Examples include certain files are not correctly packaged/included in
the PyPI sdist, such as test suite/files/data.

In these cases, use the alternative MASTER_SITES, open issues/PR's
upstream to get them included, and switch to CHEESESHOP when it lands.

This ensures an upstreams packaging/deployment pipeline is well tested
and standardised, as it is heavily relied upon (setuptools, autoplist,
documentation, discoverability, etc)

Note: Irrespective of MASTER_SITES, if a package is in PyPI it *must* be
named exactly by its . That is:

* SVN Directory: py-
* PORTNAME= 
* PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}

./koobs



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: php72-7.2.0 : trouble with lang/php72 & libargon2

[Oliver Schonrock]

On 11/12/17 23:41, Matthew D. Fuller wrote:
> On Mon, Dec 11, 2017 at 11:32:08PM + I heard the voice of
> Oliver Schonrock, and lo! it spake thus:
>> and it solves my issue as well.  Don't think the CPUTYPE stuff comes
>> into it.
> Well, maybe.  From your mail, though, it looks like you did that
> testing by rebuilding/installing the ports _on the local machine_,
> rather than rebuilding in poudriere.  If the poudriere box was
> building binaries with instructions not in your local machine, that
> local build would bypass that issue, so it may still be there.
> "Illegal instruction" seems like an odd presentation for "missing
> file".

It's a good point, I get ya. You're right, I did not retest the
poudriere build.

The Poudriere machine has a:

Intel(R) Core(TM) i3-4130T: Haswell (4th gen)

The machine that is throwing the "Illegal instruction" error, is a
VirtualBox VM running on an:
Intel(R) Core(TM) i7-2600 CPU: Sandy Bridge (2nd gen)

Our production machines are all:
CPU: AMD Opteron(tm) Processor 4386: "Seoul" (32 nm)

Ideally I would like to be able to use the packages built by the i3-4130
machine to run without hitches across all 3 CPU types, while still
taking advantage of their features for openssl/TLS, etc.

What would be a good CPUTYPE line for make.conf?

I am non-the-wiser from the docs in /usr/share/examples/etc/make.conf


-- 
Oliver Schönrock
Mobile   : +44 7880 617 446
email: oli...@schonrocks.com



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD Port: php72-7.2.0 : trouble with lang/php72 & libargon2

[Matthew D. Fuller]

On Mon, Dec 11, 2017 at 11:32:08PM + I heard the voice of
Oliver Schonrock, and lo! it spake thus:
>
> and it solves my issue as well.  Don't think the CPUTYPE stuff comes
> into it.

Well, maybe.  From your mail, though, it looks like you did that
testing by rebuilding/installing the ports _on the local machine_,
rather than rebuilding in poudriere.  If the poudriere box was
building binaries with instructions not in your local machine, that
local build would bypass that issue, so it may still be there.
"Illegal instruction" seems like an odd presentation for "missing
file".


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: php72-7.2.0 : trouble with lang/php72 & libargon2

[Matthew D. Fuller]

On Thu, Dec 07, 2017 at 08:21:05PM + I heard the voice of
Oliver Schonrock, and lo! it spake thus:
> 
> pkg check --dependencies reports problem.

This seems the separate issue already being convered.


> 1. In the worst case (when built on remote poudriere) php72 crashes when
> using the PASSWORD_ARGON2I algo for password_hash.

[...]

> 1. BAD: from poudriere
[...]
> # php -r 'echo password_hash("password", PASSWORD_ARGON2I). "\n";'
> Illegal instruction (core dumped)

This suggests the libargon compiled on the poudriere machine is using
instructions not present on the running machine; often a newer or
higher end CPU model.  Building libargon locally on the final machine
sidesteps the issue.

If that's the cause, you may well have other landmines in other
packages lying in wait, so you should try and root-cause it.  Do you
have a CPUTYPE or the like in the poudriere setup, which may be
outpacing the system you're running the final result on?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: php72-7.2.0 : trouble with lang/php72 & libargon2

[Oliver Schonrock]

On 11/12/17 23:28, Matthew D. Fuller wrote:
>> pkg check --dependencies reports problem.
> This seems the separate issue already being convered.
>
>
and it solves my issue as well. All tested just waiting for commit of
this ports tree:

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188700&action=edit

Don't think the CPUTYPE stuff comes into it.

-- 
Oliver Schönrock
Mobile   : +44 7880 617 446
email: oli...@schonrocks.com 



signature.asc
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Sebastian Schwarz]

On 2017-12-10, Stefan Esser wrote:
> Debugging shell scripts is a lot of work, since you cannot
> single step through them.

There are a few shell debuggers:

- http://bashdb.sourceforge.net/
- https://github.com/rocky/kshdb/
- https://github.com/rocky/zshdb/

However none of them is for plain POSIX Bourne Shell.  But you
might be able to run the other shells in a appropriate
compatibility mode ("bash --posix" or "env POSIXLY_CORRECT=1
bash" for example).

I haven't use the debuggers extensively, so I don't know how
well they work.  But they might be of some use to you.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Tue, 12 Dec 2017 08:54:26 +1100 (EST) "Dave Horsfall"  
said


On Mon, 11 Dec 2017, Chris H wrote:

> pf(4) has dropped any/all communication from the showdan "project" 
> *long* ago for all the systems I'm responsible for, and along with all 
> the myriad of other "like" projects. They all have the policy backward; 
> ask *before* not *after*.


I'd love to do that; what's the IP range of their scanners (I assume that 
they have more than one)?

Sure. I'll pull them out of my tables, and send you a copy off-list.


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."


--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: License and adopting software

[Greg 'groggy' Lehey]

[format recovered]

On Sunday, 10 December 2017 at 23:31:33 -0800, Chris H wrote:
> On Mon, 11 Dec 2017 12:24:53 +0800 "blubee blubeeme"  
> said
>> On Mon, Dec 11, 2017 at 12:21 PM, Jonathan Chen  wrote:
>>> On 11 December 2017 at 17:17, blubee blubeeme  wrote:
 I like some old software that's <= GPL2 but it seems like the original
 developer is not and have not done any work on the software sine mid
 2000.

 I'd like to pick up the project, fix bugs BUT i'd like to migrate
 from GPL to BSD license.

 How does one go about doing that? I have seen the GPL code but it
 could be re-written how would that affect me re-writing the code
 with a new copy center license?
>>>
>>> You basically have to get the original author to reassign copyright to
>>> you; after which you can do whatever you like to it. If you're basing
>>> your new work on the original work, you have to respect the LICENCE
>>> that it came with.
>
> It's also worth noting; you can dual-license it. That is:
> their code == their license
> your code (additions) == your license

No, you can't.  Read the conditions of the GPL license.  If you add
code to a GPL product, the additions become subject to the GPL.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: Procmail Vulnerabilities check

[Dave Horsfall]

On Mon, 11 Dec 2017, Chris H wrote:

pf(4) has dropped any/all communication from the showdan "project" 
*long* ago for all the systems I'm responsible for, and along with all 
the myriad of other "like" projects. They all have the policy backward; 
ask *before* not *after*.


I'd love to do that; what's the IP range of their scanners (I assume that 
they have more than one)?


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 20:45:11 +0100 "Kurt Jaeger"  said


Hi!

> Let me attempt to make my point another way (and stay closer to topic).
> A user is able to accomplish more from sendmail in base, than with any
> other MX port in base alone.
[list of sendmail features shortend for brevity]

> Many of the other MX software in the ports tree provide a subset of
> the shortlist I mentioned above. But none of them offer them all.

So if sendmail is a pkg/port, it would still have those features ?

Is a

pkg install sendmail

such a huge step ? And btw, even if sendmail has all those features,
I can tell you that even when I first attend my first sendmail workshop,
approx. 27 years ago, I still would not know how to implement them
with sendmail.

> I were an MX administrator. Would I not want all the options/help
> I could get to defend myself against attack?

I still don't get the difference if sendmail would be a port/pkg.

Oh, btw, if sendmail can do all this, wouldn't it be useful to
have a suitable config that does all this right out of the box ?

Because, honestly, I would not know how to enable all those features...

> True. But if I'm selling a Server targeted OS. Don't I want to
> advocate server grade services?

But the distribution channel of the software for that service
(base or port) does not sound as the relevant factor for the
end-user, or does it ?

OK. So if I'm understanding this all correctly; All the (FreeBSD) worlds
a package. So what am I arguing for Sendmail in base for? It makes no
sense -- everything's a package. Am I getting warmer? :-)
If so. Then where does it end? How many packages must I install to get a
"standard" Server install? I'm going to want cp(1), fsck(8), mkdir(1),
gpart(8),...
Wow! filling /bin/, and /sbin/ will take an awful lot of packages, and I
haven't had time to consider /usr/bin/, and /usr/sbin/ ! ;-)
As I understand it, the $BASE package is going to amount to what one
would expect, and need to get (at least) a usable system. IMHO *mail*
is an important part of *any* system. Oh wait. This is intended as part
of a simple *desktop* system? Because that's the audience FreeBSD is
currently targeting? OK than no *real* need for a robust MX there. As
they'll likely just be using their ISP for an MX, and only *really* need
a MX *client*. OK that makes more sense. :P
I'm only advocating that if $BASE is intended for a reasonable/minimal
Server base install. That an MX *is* an important part of that definition,
and that Sendmail be *that* MX. :-)

Thanks for playing along, Kurt. :-)

--Chris

P.S. Indeed. Sendmail, *can* be installed as a package, and still work,
as I think, can *anything* else. But *where* does it all end -- It's
*mad* I tell ya!


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INDEX now builds successfully on 10.x

[Ports Index build]

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 19:46:55 +0100 "Kurt Jaeger"  said


Hi!

> If you, as an administrator of a/your system(s), see no problem with
> (port) scanners, and take no action to thwart such activity. You are
> more than likely to encounter trouble(s) down the road.

Right, portscanning is bad, if not done in a transparent way,
so as sys-admin I have to reduce exposure.

But it's a valid tool, nevertheless.

> In short; I see them all as "black hats". Honestly. Can you *really*
> determine good intentions from bad intentions on an incoming port scan?

Yes. If it's done with full transparency, I don't mind scanning.

With transparency, I mean:
- reverse dns is set
- scan from the same IP all the time

They don't. For the sake of argument, I'll name showdan; they use (off
the top of my head) some 9 to 12 addresses. Addresses the move, also. :(


- some point of contact for the scan (a website, email etc)
- if requested, the scanner delivers individual results to the scanned
- if requested, one can be excluded from the scan
- all the results are only used for 'above-the-waterline' work,
 like research or statistics
- scanner is willing to be audited
- [maybe some other rules...]

In fact, I've even organised such a project doing that for TLS:

https://github.com/TLS-Check/tls-check

I respectfully agree to disagree with you on this. Mostly on one point;
I should be informed *prior* to the port scan/audit, not *after*.



I would not mind a registry at IANA for such transparent scan projects,
so that all the other ones can be traced and stopped.

This, my friend, I agree with you on, wholeheartedly. :-)

--Chris



--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Roger Marquis]

Michelle Sullivan wrote:

Personally I think if you remove Sendmail you should not replace it with
something else... but then FreeBSD is not about what I want or what the
users want anymore.


I thought there already was a viable replacement in OpenSMTPD?  The fact
that OpenBSD migrated 3 years ago makes this a no-brainer, or does
anyone think accepting mail from remote hosts needs to be part of base?

Considering just about every other open source OS distribution now uses
Postfix the potential for its license to be updated (from IPL to EPL2.0)
may be timely...


Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 19:36:49 +0100 "Kurt Jaeger"  said


Hi!

> if the majority of people install their systems via packages, that makes for
> a fairly common FreeBSD base across all users.

Why would a system installed via packaged be more homogenous than
one installed as base, and updated via freebsd-update ? I don't
understand this -- can you elaborate ?

OK. I'll try. I'm afraid I sort of went on a Jag, and didn't really make a good
point -- if *any* point. Sorry.
But to the point, and sorry for the (additional) deviation;
If I have a user base that shares a near identical install. I am far closer
to finding/having a pattern I can work with to *exploit*, as an evil hacker.
So here's the thing; working from the history of Linux, and for that matter,
even MS products... someone discovers an exploit in FreeBSD, or some component
common to FreeBSD. I can take down a *much* greater number of users, now that
the (larger) portion of FreeBSD' user base share such a common install base --
applications(ports)/kernel et al; are pretty much all the same for *everyone*
because of the introduction of pkg(8).
Yes. But what's the difference if they made everything from ports(7)?
IMHO, and experience, users confronted with options during build time, are
*more* likely to actually *choose* options that better suite their use/needs.
But using packages is easier, and so if in the end everything just *works*.
There's little incentive to use that scary "make" thing, and have to learn
all those intimidating things associated with the ports system.
Well, FLAVORS should solve all that. Wouldn't it?
That *does* seem like a strong argument, and while I applaud all the efforts,
and those that are responsible for those efforts. The jury is still out.
FLAVORS has yet to *fully* arrive. So it's just too early to say for sure.
But I would agree that it *should*.
When I look back at all the security threats that Linux had to deal with
(even now), and how the ultimate argument was so often; use *BSD, it's a
much more secure OS by design. Which was true. Linux was/is always installed
in packages, or by what ever moniker they use for them. With that, and their
choice of kernel arrangement. They were left as easier targets than the BSD
family of operating systems. Now looking at the increasingly narrowing of
differences between the two. I can't help but think that the threat vector
gap is *also* narrowing.



> In closing, and more to the point regarding Sendmail; Sendmail has a nearly
> impeccable security record in at the last decade. It provides a *secure*,
> more powerful, and more flexible MX on the cheap. I see little reason to
> consider it an attack vector. Which makes *security*, and it's related
> maintenance a pretty poor argument, for it's removal.

The argument is: The update process for base is more complex
than for packages, and we've come a long way to have a very
nice pkg-system, in general. The mid-term plan is thus to package base, too.

Packaging base means sensible packages have to be defined, and
sendmail suits a package very well.

Indeed it *does*, and *should* be a package installed *along* with $BASE.
That's my only argument there. :-)

Thanks for your thoughtful reply, Kurt!

--Chris


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports@ list is now subscriber-post only

[Roger Marquis]

Lowell Gilbert wrote:

"Thomas Mueller"  writes:

Why only the freebsd-ports mailing list and no others?
Other FreeBSD mailing lists get spam, and I thought freebsd-questions was
the biggest target for spam.


Why? 1) lack of volunteers with sufficent mailman and/or spam-filtering
experience, 2) lack of list admins with mailman moderation experience,
3) failure to accept experienced postmaster volunteers, and last but not
least 4) lack of list management policies based on best practice.


However -questions isn't one of them, because you can't ask
someone to subscribe to a list before asking for tech support.


We shouldn't need to subscribe to post to -questions, agreed 100%,
however, it takes very little skill or time to moderate posts from
unsubscribed and recently-subscribed posters.  Then again it also takes
little time or effort to configure postfix to score and hold the obvious
spam that continues to get forwarded to freebsd lists.  At least making
-ports subscriber-only is a small indication that someone on the
postmaster team recognizes there is an issue here.

IME,
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> Let me attempt to make my point another way (and stay closer to topic).
> A user is able to accomplish more from sendmail in base, than with any
> other MX port in base alone.
[list of sendmail features shortend for brevity]

> Many of the other MX software in the ports tree provide a subset of
> the shortlist I mentioned above. But none of them offer them all.

So if sendmail is a pkg/port, it would still have those features ?

Is a

pkg install sendmail

such a huge step ? And btw, even if sendmail has all those features,
I can tell you that even when I first attend my first sendmail workshop,
approx. 27 years ago, I still would not know how to implement them
with sendmail.

> I were an MX administrator. Would I not want all the options/help
> I could get to defend myself against attack?

I still don't get the difference if sendmail would be a port/pkg.

Oh, btw, if sendmail can do all this, wouldn't it be useful to
have a suitable config that does all this right out of the box ?

Because, honestly, I would not know how to enable all those features...

> True. But if I'm selling a Server targeted OS. Don't I want to
> advocate server grade services?

But the distribution channel of the software for that service
(base or port) does not sound as the relevant factor for the
end-user, or does it ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Matthias Apitz]

El día lunes, diciembre 11, 2017 a las 11:26:44a. m. -0700, Warren Block 
escribió:

> > Warren, you have not got my point: Why specfying '-d ${USER}' is required 
> > in 
> > a per user file in its HOME?

The maildrop is started as the user 'foo' by a line in a file ~foo/.forward,
as you say:

maildrop -d foo

and this '-d foo' is IMHO completely superfluous, because the maildrop could do
by its own a getuid(2) and a user 'foo' will never run (and perhaps can
not run due to lack of permissions) something like '-d bla'.

Do you copy me?

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  📱 
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


signature.asc
Description: PGP signature

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 08:39:02 -0800  said


On Mon, 11 Dec 2017 11:10:32 + "Matt Smith"  said

> On Dec 10 14:58, Chris H wrote:
>>OK I'm puzzled a bit. FreeBSD' motto has always been:
>>FreeBSD
>>The power to serve!
> >
>>but many of the proposed, and recent changes/removals end up more like:
>>FreeBSD
>>I's castrated!
> 
> The problem with software in the base is that it is *much* more 
> difficult to update to add new features or patch security issues. With a 
> port the software will be updated relatively quickly. And users can get 
> the benefits of that with a quick pkg upgrade. They might not update 
> their O/S for 6-12 months.
> 
> In my opinion any software which is accessible to the internet should be 
> patched and upgraded ASAP. It's for this reason that I've always 
> disabled things like OpenSSH/OpenSSL/ntpd etc in the base and used port 
> versions instead.

I applaud that attitude. I couldn't agree more. For that same reason, I
(not unlike you) have always excluded software that history has proven
to pose security risks ( WITHOUT_BIND=true ) for example. The same can also
*easily* be said of OpenSSL.


[ excessive "jag" removed. sorry ]


threat.
In closing, and more to the point regarding Sendmail; Sendmail has a nearly
impeccable security record in at the last decade. It provides a *secure*,
more powerful, and more flexible MX on the cheap. I see little reason to
consider it an attack vector. Which makes *security*, and it's related
maintenance a pretty poor argument, for it's removal.

--Chris

Let me attempt to make my point another way (and stay closer to topic).
A user is able to accomplish more from sendmail in base, than with any
other MX port in base alone.
Sendmail provides OOB:
block by topic/portion of topic
block forged MX
block dynamic host(s)
all with the addition of one stanza, and (in the case "topic") the
addition of TOPIC_FILE
it also provides for some other measures that trip up, or otherwise
thwart spammer tactics;
delay (E)HELO
connection THROTTLING. As well as the ability to utilize block
list services, offered by third parties, or your own personal block
list.
Many of the other MX software in the ports tree provide a subset of
the shortlist I mentioned above. But none of them offer them all.
Given that the biggest concern, both security-wise, as well
nuisance-wise from anyone managing an internet facing MX service is
SPAM, and related threats. Wouldn't one be best served, if they had
the most options available to defend against such threats?
FWIW in ~5 months only having (ever) having sendmail from base,
without the addition of any additional "plugins".
I was able to collect (and subsequently block)  ~9.9 million SPAM
sources. Not likely, but *actual* spam sources.
When I began life as a maintainer of ports. I was subsequently
required to subscribe to additional FreeBSD mailing lists, and
provide my/a email address along with the the ports I maintain.
As a result, my [that] address had a greater exposure to spammers.
In a short time, I found myself inundated with SPAM -- literally
*thousands* per day. My initial reaction was to curse the FreeBSD
ports/mailing-list management system, and those who were in charge.
But I decided against a knee-jerk reaction, and decided to give the
matter more thought, before making a decision. In the end, I decided
I wasn't going to allow myself to be a victim, but rather make the
whole matter a challenge, or puzzle that I would solve. In the end,
and with my current base version of sendmail, I now only receive
some 3-5 SPAM/week. That is a *remarkable* number, compared to my
initial experience, as the number of *actual* SPAM sources I've
been able to thwart. That 9.9 million number is not a *probable*
number, it's an actual figure, and in the end, I *always* get the
mail I want, and nearly *never* get the mail I don't. All with
sendmail from base, and without any external/third party services.
IMHO that makes a pretty strong argument for retaining Sendmail. If
I were an MX administrator. Would I not want all the options/help
I could get to defend myself against attack? This is the sort of
thing that makes FreeBSD the best choice for a Server Grade install.
It provides server grade applications in a Service oriented OS.

Yes. But if it's removed. Nothing stops you from installing it
from ports.

True. But if I'm selling a Server targeted OS. Don't I want to
advocate server grade services?

Thanks for listening -- I know it was long.

--Chris

> 
> -- 
> Matt



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> If you, as an administrator of a/your system(s), see no problem with
> (port) scanners, and take no action to thwart such activity. You are
> more than likely to encounter trouble(s) down the road.

Right, portscanning is bad, if not done in a transparent way,
so as sys-admin I have to reduce exposure.

But it's a valid tool, nevertheless.

> In short; I see them all as "black hats". Honestly. Can you *really*
> determine good intentions from bad intentions on an incoming port scan?

Yes. If it's done with full transparency, I don't mind scanning.

With transparency, I mean:
- reverse dns is set
- scan from the same IP all the time
- some point of contact for the scan (a website, email etc)
- if requested, the scanner delivers individual results to the scanned
- if requested, one can be excluded from the scan
- all the results are only used for 'above-the-waterline' work,
  like research or statistics
- scanner is willing to be audited
- [maybe some other rules...]

In fact, I've even organised such a project doing that for TLS:

https://github.com/TLS-Check/tls-check

I would not mind a registry at IANA for such transparent scan projects,
so that all the other ones can be traced and stopped.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> if the majority of people install their systems via packages, that makes for
> a fairly common FreeBSD base across all users.

Why would a system installed via packaged be more homogenous than
one installed as base, and updated via freebsd-update ? I don't
understand this -- can you elaborate ?

> In closing, and more to the point regarding Sendmail; Sendmail has a nearly
> impeccable security record in at the last decade. It provides a *secure*,
> more powerful, and more flexible MX on the cheap. I see little reason to
> consider it an attack vector. Which makes *security*, and it's related
> maintenance a pretty poor argument, for it's removal.

The argument is: The update process for base is more complex
than for packages, and we've come a long way to have a very
nice pkg-system, in general. The mid-term plan is thus to package base, too.

Packaging base means sensible packages have to be defined, and
sendmail suits a package very well.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Warren Block]

On Mon, 11 Dec 2017, Matthias Apitz wrote:

On Monday, 11 December 2017 04:56:04 CET, Warren Block  
wrote:

On Fri, 8 Dec 2017, Matthias Apitz wrote:

El día viernes, diciembre 08, 2017 a las 03:13:02p. m. -0700, Warren Block 
escribió:



Hmm, why -d ${USER} if this is already known who I am from the
~/.forward file location?


Because as a sysadmin, then you can copy it to another user without
having to edit it each time.


Hmm, and why the sysadmin has to put in each copy the '-d ${USER}' when
he/she puts the copy in the ~/.forward file of the USER?


Because it's a per-user setting?  I don't know for a fact, but that's how 
I'd do it: make the solution as general as possible.


Warren, you have not got my point: Why specfying '-d ${USER}' is required in 
a per user file in its HOME?


I guess I still don't understand.  I don't know if it's safe or good 
practice to assume $USER is set to the value of basename(~).

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: What is the preferred MASTER_SITES for python port?

[Mathieu Arnold]

Le 11/12/2017 à 18:46, Sergey Akhmatov a écrit :
> Suppose I want to port some python package that exists in the Python
> Package Index (PyPI) and has it's source code available on some
> official website or github.
>
> Is there any policy or recommended practice for choosing MASTER_SITES?
> Should I use "USE_GITHUB=yes" or "MASTER_SITES= CHEESESHOP" for such
> package?

If possible, you should always use a real release and not an extract
from a git repository.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: What is the preferred MASTER_SITES for python port?

[Chris H]

On Mon, 11 Dec 2017 20:46:43 +0300 "Sergey Akhmatov"  said


Hello.

Suppose I want to port some python package that exists in the Python 
Package Index (PyPI) and has it's source code available on some official 
website or github.


Is there any policy or recommended practice for choosing MASTER_SITES? 
Should I use "USE_GITHUB=yes" or "MASTER_SITES= CHEESESHOP" for such 
package?


I've looked for the answer in Porters Handbook and at 
https://wiki.freebsd.org/Python/PortsPolicy but haven't found it.

While this isn't the definitive answer. It may be of additional help.
/usr/ports/Mk/bsd.sites.mk
holds the *current* list of "default" sites for many of the common
locations for things not specific to just one port.

HTH

--Chris


Thank you.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INDEX build failed for 10.x

[Ports Index build]

INDEX build failed with errors:
Generating INDEX-10 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
--- describe.astro ---
--- describe.audio ---
--- describe.benchmarks ---
--- describe.biology ---
--- describe.cad ---
--- describe.chinese ---
--- describe.comms ---
--- describe.converters ---
--- describe.databases ---
--- describe.deskutils ---
--- describe.devel ---
--- describe.dns ---
--- describe.editors ---
--- describe.emulators ---
--- describe.finance ---
--- describe.french ---
--- describe.ftp ---
[...]
--- describe.ukrainian ---
--- describe.vietnamese ---
--- describe.www ---
--- describe.sysutils ---
make[5]: "/home/indexbuild/tindex/ports/sysutils/u-boot-master/Makefile" line 
102: Malformed conditional (${FAMILY} == allwinner64)
make[5]: "/home/indexbuild/tindex/ports/sysutils/u-boot-master/Makefile" line 
118: Malformed conditional (${FAMILY} == allwinner64)
make[5]: Fatal errors encountered -- cannot continue===> sysutils/u-boot-master 
failed
*** [describe.sysutils] Error code 1

make[2]: stopped in /home/indexbuild/tindex/ports

make[2]: stopped in /home/indexbuild/tindex/ports
*** Error code 1

Stop.
make[1]: stopped in /home/indexbuild/tindex/ports
*** Error code 1

Stop.
make: stopped in /home/indexbuild/tindex/ports
1 error

Committers on the hook:
 amdmi3 antoine asomers danfe dumbbell manu swills 

Most recent SVN update was:
Updating '.':
Usysutils/u-boot-master/Makefile
Usysutils/u-boot-pine64/Makefile
Usysutils/u-boot-sopine/Makefile
Usysutils/lscpu/Makefile
Dshells/fish/files
Ushells/fish/Makefile
Ushells/fish/distinfo
Ushells/fish/pkg-plist
Udevel/libosmo-sccp/Makefile
Udevel/libosmo-sccp/distinfo
Udevel/libosmo-sccp/pkg-plist
Udevel/aap/Makefile
Udevel/alf/Makefile
Udevel/blitz/Makefile
Udevel/evolution-gconf-tools/Makefile
Udevel/libnxt/Makefile
Udevel/libredblack/Makefile
Udevel/py-json-py/Makefile
Udevel/py-kqueue/Makefile
Udevel/uatraits/Makefile
Udevel/d-feet/Makefile
Udevel/gtranslator/Makefile
Ugames/sgt-puzzles/Makefile
Ugames/sgt-puzzles/distinfo
Ugames/4stattack/Makefile
Ugames/adonthell/Makefile
Ugames/battletanks/Makefile
Ugames/bombz/Makefile
Ugames/bubbros/Makefile
Ugames/diameter/Makefile
Ugames/duckmaze/Makefile
Ugames/farblazer/Makefile
Ugames/gemrb/Makefile
Ugames/golly/Makefile
Ugames/gtkradiant/Makefile
Ugames/liquidwar/Makefile
Ugames/monsterz/Makefile
Ugames/mopesnake/Makefile
Ugames/pyawale/Makefile
Ugames/pykawari/Makefile
Uastro/astrometry/Makefile
Uaudio/ardour5/Makefile
Uaudio/trommler/Makefile
Ubenchmarks/pybench/Makefile
Ubiology/pycogent/Makefile
Ucad/freecad/Makefile
Uchinese/sunpinyin/Makefile
Uchinese/ibus-libpinyin/Makefile
Uchinese/ibus-pinyin/Makefile
Ucomms/gr-osmosdr/Makefile
Ucomms/py-libimobiledevice/Makefile
Udatabases/postgresql-libpqxx/Makefile
Udatabases/postgresql-libpqxx3/Makefile
Udatabases/Makefile
Adatabases/py-sqlparse020
Adatabases/py-sqlparse020/Makefile
Adatabases/py-sqlparse020/distinfo
Adatabases/py-sqlparse020/pkg-descr
Uemulators/openmsx/Makefile
Umath/maxima/Makefile
Umath/maxima/distinfo
Umath/maxima/pkg-plist
Unet/concourse-fly/Makefile
Unet/concourse-fly/distinfo
Updated to revision 456054.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

What is the preferred MASTER_SITES for python port?

[Sergey Akhmatov]

Hello.

Suppose I want to port some python package that exists in the Python 
Package Index (PyPI) and has it's source code available on some official 
website or github.


Is there any policy or recommended practice for choosing MASTER_SITES? 
Should I use "USE_GITHUB=yes" or "MASTER_SITES= CHEESESHOP" for such 
package?


I've looked for the answer in Porters Handbook and at 
https://wiki.freebsd.org/Python/PortsPolicy but haven't found it.


Thank you.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 16:42:57 +0100 "Kurt Jaeger"  said


Hi!

> > On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> > > OK I'm puzzled a bit. FreeBSD' motto has always been:
> > > FreeBSD
> > > The power to serve!
> > > 
> > > but many of the proposed, and recent changes/removals end up more like:

> > > FreeBSD
> > > I's castrated!

> > So, then we should add a web server into our base! Apache? NGINX? Both?
> > But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
> > after all! Let's talk about fileservers. Samba! I could go on...
> OK. That's simply an irrelevant argument. I never advocated for the
> *addition* of anything. Only against the *removal* of something most users
> have come to expect with the installation of FreeBSD.

The argument was made to show the general idea, not to nit-pick 8-}

As packaging base is also on the horizon, see

https://www.youtube.com/watch?v=Br6izhH5P1I

and

https://www.youtube.com/watch?v=v7px6ktoDAI

the debate will pop up in any case.

> > FreeBSD's power to serve slogan is about delivering the platform to
> > serve, not all possible server software. [...]

> In all fairness, that's just pure supposition. I would suggest that it is
> more probable that more users use Sendmail 1) because it came with the
> FreeBSD install, and 2) as such, makes it easier to implement.

Then it's time to start some research, if this hypothesis really holds.

Thanks for the links, and the thoughtful reply, Kurt!
In all fairness, your right. *actual* numbers *do* apply. :-)



I know that the folks at dovecot.fi did this in February for dovecot, see

openemailsurvey.org

It was made using shodan, maybe it's time to do the same for port 25
via shodan ?

LOL, showdan.io! Hah! I'm *more* than a little irritated by this sort of thing.
*Sure* it can provide some useful data. But the part that really irritates
me, is that anyone think it's OK to probe my ports w/o asking. It's akin
to saying; we initiated a study to determine how many people were using the
LG model XYZ refrigerator. In that study, we peered into all the windows
of as many houses, in as many neighborhoods as possible. But please, do not
feel violated. We made every effort to look away, if we encountered anyone
naked, or in an otherwise compromising situation. If you still find this
method too intrusive. You need only tell us so. Simply come, and try to
find the link to request exclusion. Err... what?!?!
If you, as an administrator of a/your system(s), see no problem with
(port) scanners, and take no action to thwart such activity. You are
more than likely to encounter trouble(s) down the road. Even those that
take preemptive action ahead of time, to close all unused ports. History
already *proves* this fact, time, and time again. :-)
pf(4) has dropped any/all communication from the showdan "project" *long*
ago for all the systems I'm responsible for, and along with all the myriad
of other "like" projects. They all have the policy backward; ask *before*
not *after*.
In short; I see them all as "black hats". Honestly. Can you *really*
determine good intentions from bad intentions on an incoming port scan?

Still. Your point is well taken, and your point is not on the top of your
head. ;-) ;-)
We really *do* need corroborating evidence. :-)

Thanks again, all the best to you, Kurt!

--Chris


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
vs the soundcard.h in the offical OSS 4.01
https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

It seems like there's been a lot of changes between FreeBSD 3.8ish version
and the 4.0 version.

I was grepping around to see if any other files included this soundcard.h
header and if updating to the latest would break any other programs.

Is there anyone here who actively work on OSS have a moment for a few
questions?

On Tue, Dec 5, 2017 at 8:48 AM, blubee blubeeme  wrote:

> For me the why is simple.
>
> I want the best possible audio for my system. I work with synthesizers and
> audio programs a lot and on Linux for pro audio everyone recommended using
> Jack sound server, which was always a pain to maintain, keep connections
> between sessions, etc...
>
> After learning more about audio, I realized that Jack only complicated
> things and OSS can do what jack without needing the additional complexity
> of Jack server.
>
> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.
>
> this: https://static.lwn.net/images/2013/audio-session/3-
> non-session-manager.png
> is what some audio setup looks like, then you have jack in the background
> like this: http://libremusicproduction.com/sites/default/files/articles/
> Qjackctl.png
>
> It almost never works if you try to save a session and restore it,
> something always breaks and that just ruins any motivation I had to
> continue a music project.
>
>
>
> This: http://manuals.opensound.com/developer/ossapi.html
> gives basically the same overview you provided above.
>
> Another reason why is because I prefer simplicity over complexity, sure
> FreeBSD sound is feature compatible with 4Front OSS but at the same time
> everyone is always saying how FreeBSD is short on developers but want to
> fork of an actively developed and maintained project? https://sourceforge.
> net/p/opensound/git/ci/master/tree/
>
> Why not let them keep on working on the project and pull that in so that
> we can always stay on top of what they are doing? Does FreeBSD have enough
> manpower to fork and maintain the project?
>
> I know one thing, I ran osstest on my system and I was shocked how great
> my sound system is, for the past year the audio has always been tinny and
> weird but now I am moving to make OSS my default audio driver and work in
> support for all the apps/ tools that I use.
>
> So that's why i'd like to have the official 4Front OSS drivers instead of
> a fork.
>
>
> On Tue, Dec 5, 2017 at 12:26 AM, Jan Beich  wrote:
>
>> blubee blubeeme  writes:
>>
>> > On Mon, Dec 4, 2017 at 8:08 PM, Jan Beich  wrote:
>> >
>> >> blubee blubeeme  writes:
>> >>
>> >> > I'm looking at the information for audio/oss and it seems that the
>> source
>> >> > used is different than the 4frontversion.
>> >> >
>> >> > -
>> >> >
>> >> > This port uses installation procedure that is very different from
>> >> > the one used by 4Front and is not supported by them.
>> >> >
>> >> > -
>> >> >
>> >> > The port also seems to lack a maintainer but a lot of work is being
>> >> > committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.
>> >>
>> >> Well, you've answered your own question. There's no maintainer to check
>> >> which downstream differences still make sense.
>> >>
>> >> What is better maintained[1] and supported is FreeBSD fork of OSS -
>> >> sound(4).
>> >> See OSSv4 compatibility in https://people.freebsd.org/~
>> >> ariff/SOUND_4.TXT.html
>> >> Not sure why those bits haven't migrated into the manpage.
>> >>
>> >> [1] 4Front vs. FreeBSD commit activity:
>> >> https://sourceforge.net/p/opensound/git/ci/master/log/
>> >> https://svnweb.freebsd.org/base/head/sys/dev/sound/?view=log
>> >>
>> > Thanks for the heads up, I am still learning my way around so I might
>> ask
>> > questions that don't seem to make sense sometimes.
>> >
>> > Since there is no maintainer and the FreeBSD OSS is a fork [I'd assume]
>> of
>> > an earlier version, wouldn't it be wise to port over the new OSS 4.xx
>> since
>> > this page: http://manuals.opensound.com/developer/ossapi.html
>> > lists a lot of benefits for the new 4.xx version.
>>
>> Why? Not much of 4Front code is left[1] in FreeBSD implementation and
>> OSSv4 API is already supported.
>>
>> Please, be more specific what exactly you're missing.
>>
>> [1] See https://wiki.freebsd.org/Sound and copyrights under sys/dev/sound
>>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavor part of package origin?

[Julian Elischer]

On 11/12/17 9:38 pm, Mathieu Arnold wrote:

Le 11/12/2017 à 10:12, Stefan Esser a écrit :

$ pkg info -o '*setuptools*'
py27-setuptools-36.5.0 devel/py-setuptools@py27
py36-setuptools-36.5.0 devel/py-setuptools@py36


I really do not like the look of this. The origin always has been a
directory name, with this change, it would become some abstract thing.
don't concentrate on the syntax, but the idea.. It SHOULD somehow be 
represented in the origin I think..

or the origin becomes useless.






___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 11:10:32 + "Matt Smith"  said


On Dec 10 14:58, Chris H wrote:
>OK I'm puzzled a bit. FreeBSD' motto has always been:
>FreeBSD
>The power to serve!
>
>but many of the proposed, and recent changes/removals end up more like:
>FreeBSD
>I's castrated!

The problem with software in the base is that it is *much* more 
difficult to update to add new features or patch security issues. With a 
port the software will be updated relatively quickly. And users can get 
the benefits of that with a quick pkg upgrade. They might not update 
their O/S for 6-12 months.


In my opinion any software which is accessible to the internet should be 
patched and upgraded ASAP. It's for this reason that I've always 
disabled things like OpenSSH/OpenSSL/ntpd etc in the base and used port 
versions instead.

I applaud that attitude. I couldn't agree more. For that same reason, I
(not unlike you) have always excluded software that history has proven
to pose security risks ( WITHOUT_BIND=true ) for example. The same can also
*easily* be said of OpenSSL.
However, the same argument can't be made for Sendmail. Further, if I take
your argument to it's logical end. I am left with only the kernel? At what
point is enough, enough? Is the new pkg(8) system simply an attempt to make
FreeBSD the new Debian? Where everything is installed via (a) pkg? I *dearly*
hope not. The thought makes me shudder. Not that I hate Debian/Linux. Just
that I *prefer* FreeBSD, or at least a *BSD. Taking that thought a bit further;
if the majority of people install their systems via packages, that makes for
a fairly common FreeBSD base across all users. Speaking (again) of security;
doesn't this lower the bar for entry for hacking the FreeBSD (user) base?
IOW if the majority installs their systems via packages, their systems will
all be *quite* similar. If I, an evil hacker, *knows* of an entry point/flaw/...
Then I can take down a *much* larger portion of FreeBSD users, than was
usually available to me. *This* point alone, seems the biggest argument
*against* "packaging everything". IOW because it's easier, does *not* make
it better. In the big scheme of things, it really makes it *lazier*. Or at
least makes it easier to be so. One *could* argue that it *encourages* it.
But I'm only speaking from decades of support/IT work. I *know* it's true,
and I'm *not* suggesting that FreeBSD is *advocating it*. Only that (my)
history, and experience proves that it is largely human nature to take the
least line of resistance. Which in this case says history will show that the
addition of a packaged system will raise number of people vulnerable to
threat.
In closing, and more to the point regarding Sendmail; Sendmail has a nearly
impeccable security record in at the last decade. It provides a *secure*,
more powerful, and more flexible MX on the cheap. I see little reason to
consider it an attack vector. Which makes *security*, and it's related
maintenance a pretty poor argument, for it's removal.

--Chris


--
Matt



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> > On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> > > OK I'm puzzled a bit. FreeBSD' motto has always been:
> > > FreeBSD
> > > The power to serve!
> > > 
> > > but many of the proposed, and recent changes/removals end up more like:
> > > FreeBSD
> > > I's castrated!

> > So, then we should add a web server into our base! Apache? NGINX? Both?
> > But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
> > after all! Let's talk about fileservers. Samba! I could go on...
> OK. That's simply an irrelevant argument. I never advocated for the
> *addition* of anything. Only against the *removal* of something most users
> have come to expect with the installation of FreeBSD.

The argument was made to show the general idea, not to nit-pick 8-}

As packaging base is also on the horizon, see

https://www.youtube.com/watch?v=Br6izhH5P1I

and

https://www.youtube.com/watch?v=v7px6ktoDAI

the debate will pop up in any case.

> > FreeBSD's power to serve slogan is about delivering the platform to
> > serve, not all possible server software. [...]

> In all fairness, that's just pure supposition. I would suggest that it is
> more probable that more users use Sendmail 1) because it came with the
> FreeBSD install, and 2) as such, makes it easier to implement.

Then it's time to start some research, if this hypothesis really holds.

I know that the folks at dovecot.fi did this in February for dovecot, see

openemailsurvey.org

It was made using shodan, maybe it's time to do the same for port 25
via shodan ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 11:49:06 +0100 "Lars Engels"  said


On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> OK I'm puzzled a bit. FreeBSD' motto has always been:
> FreeBSD
> The power to serve!
> 
> but many of the proposed, and recent changes/removals end up more like:

> FreeBSD
> I's castrated!
> 


So, then we should add a web server into our base! Apache? NGINX? Both?
But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
after all! Let's talk about fileservers. Samba! I could go on...

OK. That's simply an irrelevant argument. I never advocated for the
*addition* of anything. Only against the *removal* of something most users
have come to expect with the installation of FreeBSD.



FreeBSD's power to serve slogan is about delivering the platform to
serve, not all possible server software. It just happens to have a mail
server in base because it always had, that's nothing that needs to be
kept forever. Probably 99% of the users don't use sendmail and the
remaining 1% know how to configure it, so installing them from ports is
a trivial thing for them.

In all fairness, that's just pure supposition. I would suggest that it is
more probable that more users use Sendmail 1) because it came with the
FreeBSD install, and 2) as such, makes it easier to implement. 3) Sendmail
is more robust/flexible OOB than than the other alternatives *without* the
addition of other software/plugins. 4) An administrator *needs* (at least)
daily logs, because... 5) Security is important, and Sendmail is cheap, and
(unlike the bind) has a reasonable security track record.

I would also argue that the most likely reason users don't like Sendmail,
is because they aren't comfortable with m4(1).

--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavor part of package origin?

[Stefan Esser]

Am 11.12.17 um 16:10 schrieb RW via freebsd-ports:
> On Mon, 11 Dec 2017 14:38:59 +0100
> Mathieu Arnold wrote:
> 
>> Le 11/12/2017 à 10:12, Stefan Esser a écrit :
>>> $ pkg info -o '*setuptools*'
>>> py27-setuptools-36.5.0 devel/py-setuptools@py27
>>> py36-setuptools-36.5.0 devel/py-setuptools@py36  
>>
>>
>> I really do not like the look of this. The origin always has been a
>> directory name, with this change, it would become some abstract thing.

The origin is used by tools to identify the location in the ports tree that
allows to build a package. With FLAVOR support, knowing the directory is
insufficient to build a package - for that reason the @FLAVOR notation has
been used in a few places already, e.g. in the MOVED file and for dependency
declarations.

> It's not all that abstract if you can simply strip the end part off. 

The directory is /usr/ports/${origin%@*} in that case, and this stripping of
the FLAVOR is already required and used in e.g. bsd.ports.mk.

With origin@flavor, there is an alternate identifier that is equivalent to
the PKGNAME, and this information is used in port management tools, e.g.
when a port is to be rebuilt for a given PKGNAME.

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavor part of package origin?

[RW via freebsd-ports]

On Mon, 11 Dec 2017 14:38:59 +0100
Mathieu Arnold wrote:

> Le 11/12/2017 à 10:12, Stefan Esser a écrit :
> > $ pkg info -o '*setuptools*'
> > py27-setuptools-36.5.0 devel/py-setuptools@py27
> > py36-setuptools-36.5.0 devel/py-setuptools@py36  
> 
> 
> I really do not like the look of this. The origin always has been a
> directory name, with this change, it would become some abstract thing.

It's not all that abstract if you can simply strip the end part off. 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

somone able to make a simple fix to net/ftp?

[Julian Elischer]

change 445013 added the following patch. unfortunatly it need to to be 
only applied if we are in 11 or 12.


Two possibilities:

1/ add a term to only act if __FreeBSD_version < 110

or

2/ don't apply the patch under 10x.

not sure which is easier.


Julian


1 
 
	--- lft_lib.h.orig 2017-07-04 09:02:47 UTC
2 
 
	+++ lft_lib.h
3 
 
	@@ -277,7 +277,7 @@ typedef struct _incomicmpicmp
4 
 
	#define EVT_INCOMING_ICMP_ICMP 75
5 
 
	#define EVT_RCVD_ICMP_ICMP 76
6 
 
	
7 
 
	-#if defined(BSD_IP_STACK) && !defined(OPENBSD)
8 
 
	+#if defined(BSD_IP_STACK) && !defined(OPENBSD) && !defined(__FreeBSD__)
9 
 
	#define SCREWED_IP_LEN
10 
 
	#endif


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

RE: The ports@ list is now subscriber-post only

[Carmel NY]

On Monday, December 11, 2017 9:17 AM, Lowell Gilbert stated:
> "Thomas Mueller"  writes:
> 
> > Why only the freebsd-ports mailing list and no others?
> >
> > Other FreeBSD mailing lists get spam, and I thought freebsd-questions was
> the biggest target for spam.
> 
> A fair number of FreeBSD lists *are* subscriber-only already.
> 
> However -questions isn't one of them because you can't ask someone to
> subscribe to a list before asking for tech support.

Excuse me, but I have had to subscribe to numerous lists before posting; i.e., 
the postfix forum
being an example. Peersonally, I think the FreeBSD team has dragged their feet 
on this matter
way to long to begin with.

-- 
Carmel


pgpBhMe9W1i1I.pgp
Description: PGP signature

Re: The ports@ list is now subscriber-post only

[Lowell Gilbert]

"Thomas Mueller"  writes:

> Why only the freebsd-ports mailing list and no others? 
>
> Other FreeBSD mailing lists get spam, and I thought freebsd-questions was the 
> biggest target for spam.

A fair number of FreeBSD lists *are* subscriber-only already.

However -questions isn't one of them, because you can't ask
someone to subscribe to a list before asking for tech support.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavor part of package origin?

[Mathieu Arnold]

Le 11/12/2017 à 10:12, Stefan Esser a écrit :
> $ pkg info -o '*setuptools*'
> py27-setuptools-36.5.0 devel/py-setuptools@py27
> py36-setuptools-36.5.0 devel/py-setuptools@py36


I really do not like the look of this. The origin always has been a
directory name, with this change, it would become some abstract thing.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Flavor part of package origin?

[Mathieu Arnold]

Le 10/12/2017 à 20:17, Christian Weisgerber a écrit :
> Shouldn't the FLAVOR be part of the package origin?
>
> $ pkg info -o '*setuptools*'
> py27-setuptools-36.5.0 devel/py-setuptools
> py36-setuptools-36.5.0 devel/py-setuptools

The flavor is registered as an annotation:

# pkg info -A '*setuptools'
py27-setuptools-36.5.0:
    flavor : py27
py34-setuptools-36.5.0:
    flavor : py34
py35-setuptools-36.5.0:
    flavor : py35
py36-setuptools-36.5.0:
    flavor : py36


-- 
Mathieu Arnold



signature.asc
Description: OpenPGP digital signature

Re: make reinstall does not work

[Walter Schwarzenfeld]

Yes, someone told me on freebsd irc-channel EOL is 30.11. Later I see 
EOL really is on 30.4.2018.


But no problem, now I have 10.4.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Mathieu Arnold]

Le 08/12/2017 à 23:46, Walter Schwarzenfeld a écrit :
> Sorry for the noise. I had overlooked 10.3 was EOL on 30.11.


11.0 was, 10.3 is still supported.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: make reinstall does not work

[Stefan Esser]

Am 11.12.17 um 12:38 schrieb Stefan Esser:
> Am 09.12.17 um 00:29 schrieb Shawn Webb:
>> On Fri, Dec 08, 2017 at 10:35:50PM +0100, Walter Schwarzenfeld wrote:
>>> I had a strange error: Make reinstall does not work anymore in the port
>>> (10.3-amd64) also FORCE_PKG_REGISTER.
>>>
>>> All other make commands works fine. I don't know if it is related to
>>> FLAVORS.
>>>
>>> make reinstall ended up e.g. with:
>>>
>>> ??Registering installation for gtk2-2.24.31
>>> *** Error code 70
>>>
>>> Stop.
>>> make[2]: stopped in /usr/ports/x11-toolkits/gtk20
>>> *** Error code 1
>>>
>>> Stop.
>>> make[1]: stopped in /usr/ports/x11-toolkits/gtk20
>>> *** Error code 1
>>>
>>> Any idea or suggestion?
>>
>> This is due to this commit:
>> https://github.com/freebsd/pkg/commit/7991c49665419916210ad589d4a85fd2a7f58b37
>>
>> The standard procedure for reinstall is to do a deinstall first. I
>> guess it's pretty common just to issue `make reinstall` (which is what
>> I used to do as well). However, that's not the originally intended
>> behavior as designed in the Ports build framework.
>>
>> So: just do a `make deinstall reinstall`. It'll work that way.
> 
> "make reinstall" combines 2 actions:
> 
> 1) De-installation of the currently installed version of the port, if any.

Hmmm, seems I was wrong about this aspect ...

There was no implicit de-installation, just FORCE_PKG_REGISTER being passed
to the sub-sequent "make install", it appears. And forcing the installation
in that way does not seem to work anymore ...

> 2) Installation of  the port even if the work directory contains the tag-files
>that indicate that the port has already been installed after building.
> 
> If you did not complete an installation of a freshly built port, then
> "make deinstall reinstall" is equivalent to "make deinstall install" and ought
> to be equivalent to a plain "make reinstall" IMHO.
> 
> Could the "70" correspond to the SQLITE_INDEX_CONSTRAINT_ISNOTNULL error code
> returned by SQlite operating on the package DB?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Walter Schwarzenfeld]

I filed a PR.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224244

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Stefan Esser]

Am 09.12.17 um 00:29 schrieb Shawn Webb:
> On Fri, Dec 08, 2017 at 10:35:50PM +0100, Walter Schwarzenfeld wrote:
>> I had a strange error: Make reinstall does not work anymore in the port
>> (10.3-amd64) also FORCE_PKG_REGISTER.
>>
>> All other make commands works fine. I don't know if it is related to
>> FLAVORS.
>>
>> make reinstall ended up e.g. with:
>>
>> ??Registering installation for gtk2-2.24.31
>> *** Error code 70
>>
>> Stop.
>> make[2]: stopped in /usr/ports/x11-toolkits/gtk20
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /usr/ports/x11-toolkits/gtk20
>> *** Error code 1
>>
>> Any idea or suggestion?
> 
> This is due to this commit:
> https://github.com/freebsd/pkg/commit/7991c49665419916210ad589d4a85fd2a7f58b37
> 
> The standard procedure for reinstall is to do a deinstall first. I
> guess it's pretty common just to issue `make reinstall` (which is what
> I used to do as well). However, that's not the originally intended
> behavior as designed in the Ports build framework.
> 
> So: just do a `make deinstall reinstall`. It'll work that way.

"make reinstall" combines 2 actions:

1) De-installation of the currently installed version of the port, if any.

2) Installation of  the port even if the work directory contains the tag-files
   that indicate that the port has already been installed after building.

If you did not complete an installation of a freshly built port, then
"make deinstall reinstall" is equivalent to "make deinstall install" and ought
to be equivalent to a plain "make reinstall" IMHO.

Could the "70" correspond to the SQLITE_INDEX_CONSTRAINT_ISNOTNULL error code
returned by SQlite operating on the package DB?

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Stefan Esser]

Am 09.12.17 um 00:22 schrieb Kevin Oberman:
> On Fri, Dec 8, 2017 at 2:52 PM, Greg 'groggy' Lehey 
> wrote:
> 
>> [rearranged]
>>
>> On Friday,  8 December 2017 at 23:42:40 +0100, Jaap Akkerhuis wrote:
 On Dec 8, 2017, at 22:35, Walter Schwarzenfeld <
>> w.schwarzenf...@utanet.at> wrote:

 I had a strange error: Make reinstall does not work anymore in the port
>> (10.3-amd64) also FORCE_PKG_REGISTER.

 All other make commands works fine. I don't know if it is related to
>> FLAVORS.

 make reinstall ended up e.g. with:

  Registering installation for gtk2-2.24.31
 *** Error code 70

 Stop.
>>>
>>> When I see this Error code 70 I do a make deinstall and then a make
>>> install. That worked for me
>>
>> Yes, I've seen this too and used the same workaround.
>>
>> Has something changed?  Does 'make reinstall' still work for others?
>>
>> Greg
>>
> 
> I regularly use 'make reinstall'  and it still worked yesterday.
> 
> # cd /usr/ports/devel/py-setuptool
> # make FLAVOR=py27
> # make FLAVOR=py27 deinstall

This step removed the package from the system ...

> # make FLAVOR=py27 reinstall

This is now equivalent to a plain "make install"

I.e. you are always performing the "deinstall install" sequence that has
been mentioned as a work-around for when "make reinstall" fails with error
code 70 ...

> # make FLAVOR=py27 clean

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
editors/latexila| 3.22.1  | 3.27.1
+-+
multimedia/motion   | 4.0.1   | 
release-4.1.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Michelle Sullivan]

Lars Engels wrote:

On Mon, Dec 11, 2017 at 09:09:39AM +1100, Dave Horsfall wrote:

On Sun, 10 Dec 2017, Adam Weinberger wrote:


DMA is a phenomenal program and is totally sufficient for a large
percentage of our user-base. I wasn’t aware of the lack of .forward
support, and I completely agree that that’s a very detrimental omission.

What about its spam filtering, such as /etc/mail/access and DNSBLs etc?


pkg install $some_spam_filtering_software_of_your_choice

That's not what belongs into base.



He didn't say spam filtering software.  Sendmail in base may be 
neutered, but it includes basic access controls and spam filtering 
rules.  Does the Dragonfly Mail Agent?


Personally I think if you remove Sendmail you should not replace it with 
something else... but then FreeBSD is not about what I want or what the 
users want anymore.


Michelle
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Lars Engels]

On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> OK I'm puzzled a bit. FreeBSD' motto has always been:
> FreeBSD
> The power to serve!
> 
> but many of the proposed, and recent changes/removals end up more like:
> FreeBSD
> I's castrated!
> 

So, then we should add a web server into our base! Apache? NGINX? Both?
But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
after all! Let's talk about fileservers. Samba! I could go on...

FreeBSD's power to serve slogan is about delivering the platform to
serve, not all possible server software. It just happens to have a mail
server in base because it always had, that's nothing that needs to be
kept forever. Probably 99% of the users don't use sendmail and the
remaining 1% know how to configure it, so installing them from ports is
a trivial thing for them.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Lars Engels]

On Mon, Dec 11, 2017 at 09:09:39AM +1100, Dave Horsfall wrote:
> On Sun, 10 Dec 2017, Adam Weinberger wrote:
> 
> > DMA is a phenomenal program and is totally sufficient for a large 
> > percentage of our user-base. I wasn’t aware of the lack of .forward 
> > support, and I completely agree that that’s a very detrimental omission.
> 
> What about its spam filtering, such as /etc/mail/access and DNSBLs etc?
> 

pkg install $some_spam_filtering_software_of_your_choice

That's not what belongs into base.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavor part of package origin?

[Stefan Esser]

Am 10.12.17 um 21:20 schrieb Kurt Jaeger:
> Hi!
> 
>> Shouldn't the FLAVOR be part of the package origin?
>>
>> $ pkg info -o '*setuptools*'
>> py27-setuptools-36.5.0 devel/py-setuptools
>> py36-setuptools-36.5.0 devel/py-setuptools
> 
> Yes, but it seems this works:
> 
> $ pkg info -o '*setuptools*'
> py27-setuptools-36.5.0 devel/py27-setuptools
> py34-setuptools-36.5.0 devel/py34-setuptools
> py35-setuptools-36.5.0 devel/py35-setuptools
> py36-setuptools-36.5.0 devel/py36-setuptools
> 
> with pkg 1.10.99.5

But that output is wrong for a system with ports built after FLAVOR support
has been activated.

I have already asked portmgr, whether it might be possible, to consider the
flavor as a required part of the origin. That should lead to the following
output for the first command example:

$ pkg info -o '*setuptools*'
py27-setuptools-36.5.0 devel/py-setuptools@py27
py36-setuptools-36.5.0 devel/py-setuptools@py36

I'd also like to have a make target "list-pkgname-flavors", which should
provide somewhat similar output when run in a port directory:

$ cd /usr/ports/devel/py-setuptools
$ make list-pkgname-flavors
py27-setuptools-36.5.0 py27
py36-setuptools-36.5.0 py36

The purpose is to easily identify the FLAVOR to be passed when building some
package with a known name and is the counterpart to querying the FLAVOR of a
package from the pkg DB.

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: php72-7.2.0 : trouble with lang/php72 & libargon2

[Oliver Schonrock]

On 11/12/17 02:30, Christopher Hall wrote:
>> Error: /usr/local/bin/php is linked to /usr/local/lib/libargon2.so
>> which does not have a SONAME.  security/libargon2 needs to be fixed.
>>
>> I would say that this is the cause of the problem. So at first 
>> Christopher - the maintainer of libargon2 - needs to fix libargon.
>> Than i can fix PHP. :)
>  
> I closed out my existing bug #222344 on libargon2 pkg-config support and
> put the entire patch to add both pkg-config and SONAME support as an
> attachment to bug #224190.
> 
> Would you try this patch to see if it fixes the problem.
> 

works for me:

# cd /usr/ports/security/libargon2/
# make deinstall clean
# wget -qO-
'https://bz-attachments.freebsd.org/attachment.cgi?id=188700&action=diff&format=raw&headers=1'
| patch -p3

# cd /usr/ports/lang/php72
# make deinstall clean install

# # builds both php72 and libargon

# pkg check --dependencies
Checking all packages: 100%

# php -r 'echo password_hash("password", PASSWORD_ARGON2I). "\n";'
$argon2i$v=19$m=1024,t=2,p=2$Vm1uSkpXLldNZnBxZWhxeQ$qGk/xMWUTuOz9yGFXFPCJi4HK5vexbFkQ14msvEYcPY

Good to commit?

Thanks


-- 
Oliver Schönrock
email: oli...@schonrocks.com



signature.asc
Description: OpenPGP digital signature

Re: Doc update for java/jdk8-doc

[Kurt Jaeger]

Hi!

> Any committer willing to review and commit the java/jdk8-doc PR:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223172
> 
> It's been on the queue for almost 2 months now.

Done, thanks for the heads-up!

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"