Re: New questions on moving to github

[Keith Mendoza]

On Mon, Jun 4, 2018, at 9:31 AM, Bart Van Assche wrote:
> On 06/04/18 17:22, Wes Hardaker via Net-snmp-coders wrote:
> > So, I assume most people have seen that Microsoft is purchasing github.
> > We were just about to move Net-SNMP to GitHub, and certainly still can.
> > But it's definitely time to check whether we still want to go this
> > direction.  I see the following options:
> > 
> > 1) Continue our path and timeline as is
> > 2) Pause the move while we see what Microsoft has planned for the future
> > of GitHub; we really have no idea what their intent is at this point
> > 3) Find someplace else
> > 
> > I'd love to hear people's opinions.
> 
> Maybe we should wait a few days to let the dust settle? Although I 
> regret the acquisition of github by Microsoft, I'm not sure we have a 
> good alternative. As far as I know github has a much better 
> infrastructure than any other open source hosting site. If in the future 
> github would become inappropriate then we can move again. It's not that 
> hard to move a git repository. Moving the wiki pages is not that easy 
> unfortunately.

I feel the same was as Bart on this. Regarding the wiki: In github, a project's 
wiki can be tied to a specifically named branch in the project repo. So, it 
might be worth looking into doing that with the existing wiki should a need to 
relocate arise again.

> 
> The optimist view is that Microsoft may well realize that any changes 
> that the open source community will perceive as evil will cause a mass 
> migration away from github and hence that they will refrain from such 
> changes.
> 

IMO, I think MS has finally given up fighting the open source/open standards 
community (or, at least I don't think they will as long as Nadella is the CEO). 
I think the amount of projects that Microsoft has since open-source (albeit 
quietly) on GitHub indicates that they've learned the errors of their ways back 
in the 90's. Might I also point out that they have announced the disbanding of 
their Windows dev team, and their latest "product" (Azure Sphere) is running 
Linux. I'm no Microsoft fanboy; but, I'm willing to give them the benefit of 
the doubt at this point.

> Bart.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: On the nature of backward comparability

[Keith Mendoza]

On Tue, May 15, 2018, at 12:58 PM, Wes Hardaker wrote:
> Keith Mendoza <ke...@icei.org> writes:
> 
> > Now that development is going to be done on github, what I would
> > recommend is forking from the official net-snmp and then maybe create
> > a branch on your github fork.
> 
> Why do you think that's better than submitting it as a branch within the
> offical fork?  Just to reduce object growth?

That, and experience tells me that replacing the build system is one of those 
projects best done in a separate area, if you will. If a "cmake conversion" 
branch is used, I would suggest limiting how often master is merged into this 
branch. That way its easier to figure out where breaking changes occurs. We 
almost have to go back to the old-school way of software development where you 
had a separate "maintenance" team where junior devs were placed--except, let's 
not actually punt it to a bunch of junior devs ;)

> 
> > That way github's merge request can be utilized fully.
> 
> How does that help in this case?  I guess it allows commenting on
> individual changes, but I think the changes are likely too large to be
> beneficial to that.
> 
> > We from ICEI (ian, Eric, me) are interested in seeing what you have so
> > far and maybe we can help pick up from there.
> 
> One of the problems I know we'll hit is that the patch was done against
> a much earlier point between 5.7 and 5.8 and there will be conflicts and
> issues because of it.  But I will try to get that branched from
> hopefully the right point where it still works.

If this was done against a known 5.7.x git tag (even one converted from 
CVS/Subversion) it might not be a bad place to complete the conversion from. 
Since it's a well-known point from git's POV git bisect should help in figuring 
out which places it breaks between the conversion and master branch, especially 
with a script that can configure with as many options as possible.

> 
> -- 
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: On the nature of backward comparability

[Keith Mendoza]

Wes

On Mon, May 14, 2018, at 4:40 PM, Wes Hardaker via Net-snmp-coders wrote:

> 
> We (my last employee) received a patch from a company that implemented a
> cmake build system for some percentage of the code.  It was better in
> many ways and had issues in others as it was a different form of
> complexity.  But it was also incomplete, but a start.  The goal was to
> put that into a public git branch but looking quickly I don't see that
> done.  I'll try to push some buttons and see if I can get that done.
> 

Now that development is going to be done on github, what I would recommend is 
forking  from the official net-snmp and then maybe create a branch on your 
github fork. That way github's merge request can be utilized fully. We from 
ICEI (ian, Eric, me) are interested in seeing what you have so far and maybe we 
can help pick up from there.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: On the nature of backward comparability

[Keith Mendoza]

Wes,
Thank you for taking the time to put the history of Net-SNMP's codebase to 
paper. I feel that it puts why the codebase is the way it is in its proper 
perspective.

After reading this very insightful essay, I feel that  Net-SNMP being the 
"de-facto SNMP stack" also means that it's the reference implementation of the 
SNMP protocol. I will address some of the points below from that perspective.

On Mon, May 14, 2018, at 2:07 PM, Wes Hardaker via Net-snmp-coders wrote:
> 
> Developing the code ended up in roughly the
> following notions/priorities:
> 
> D) Ideally, compartmentalize code into files that could be included and
>excluded at will via configure flags.  The mib-modules are done this
>way, as are the transports, SNMPv3 security modules, etc.  You get to
>compile in only te items you need.  And the mib-module's hardware
>abstraction layers (HAL) meant that the code that dealt with SNMP
>representations could be put into one file, and all the system
>dependent code could be put into OS or hardware specific files to
>implement the abstraction layers.  This is what lead to directories
>of code files like agent/mibgroup/host/data_access, for example.
> 
> E) We would maintain a number of back-release branches to help support
>those unwilling to move forward for one reason or another (often
>because they forked the code for internal use and the merge of a
>later branch didn't go as cleanly as they hoped).  Thus, we have a
>number of back branches and LTS branches which we've maintained much
>longer than promised).

This is my vision for how the Net-SNMP codebase could be restructured to 
achieve a clean code, and backwards compatibility (hopefully, the ASCII art 
displays nicely on most email clients)

---
| DEVICE/OS   |
---
 |
 |

|  SNMP CORE |

 |
 |
--
|  Communications |
--

Very briefly, SNMP CORE would contain API or function definitions that would be 
used by the agents or the command-line clients. DEVICE/OS could be 
implementation of functions that the agent needs to collect device or OS 
information. Communications would be network connection send/receive.

> 
> But, I urge caution when we collectively decide who are target audience
> is.  We don't know, and have no way to measure, the usage of Net-SNMP on
> architectures it's deployed on.  I could wax philosophically on why I
> think we have so little data, but won't.  One major point worth noting
> is that we are the defacto SNMP stack for every operating system but
> windows.  Almost.
> 
> And more importantly, we don't know what APIs and what #defines are
> being used in code bases out in the wild.  The original code, way way
> way back when, was not properly architected to provide a public/internal
> names space and we suffer from that still today.

We could take this opportunity to collect these information. As the saying 
goes, you won't know for sure until you bring the product to market.

>  
> Should we abandon them and say "from the 6.0 line we're only supporting
> X,Y and Z"?  I don't know.  But I do know we can't move forward without
> reopening the discussion.  One of the reasons that people took so so so
> long (15+ years) to switch from UCD-SNMP to Net-SNMP is that we did just
> what I'm talking about: we broke the API in a number of places and
> people were afraid to move, even though we had configure options to
> enable as much backward compatibility as possible.
> 

I think drawing a line in the sand--if you will--would be a good idea for the 
longevity of the project. Forgive the shameless plug; but, one of ICEI's 
mission is to help hone the next generation of developers who can continue the 
development of software like Net-SNMP. A spick and span codebase will allow for 
more contributors to come on board, and help address user issues. Who knows, it 
might even make it easier to support older hardware.

At the same token, drawing a line on the sand doesn't mean abandon them 
completely. A pick-up sports game, might be a good analogy. The supported 
systems could be what the current dev team has access to. Those who wish to 
support other systems, could contribute code accordingly. Ideally, in the long 
term we end up with a group of people who are leads for the different supported 
system who will make up part of the Net-SNMP core dev team.  


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

That is a very useful list. What I would recommend though is we should finish 
dealing with the #ifdef hell and replacing autotools with cmake first. That way 
if we have to onboard new people to the project they are dealing with the 
"cleaned-up" code base.

On Sun, May 13, 2018, at 6:37 PM, Robert Story wrote:
> On Sun, 13 May 2018 18:15:16 -0700 Keith wrote:
> KM> On Sun, May 13, 2018, at 3:41 PM, Bart Van Assche wrote:
> KM> > Should a list of to-do items be added to the Net-SNMP wiki?  
> KM> 
> KM> I think a to-do wiki page on github would be a good idea to
> KM> deal with what needs to be done. Then, as each item is tackled
> KM> we should have a wiki page that details the requirement for
> KM> each list item. 
> 
> There is an ancient TODO list here:
> 
>   http://www.net-snmp.org/docs/TODO.html
> 
> Something in the wiki would probably be better, and we can redirect
> that static page to the wiki...
> 
> Robert


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Sun, May 13, 2018, at 3:41 PM, Bart Van Assche wrote:
> On 04/12/18 08:31, Ian Bruene wrote:
> > This morning we (Keith, Ian) met with an assortment of the NET-SNMP 
> > developers / contributors (primarily Bart Van Assche) to discuss how we 
> > could best help the project. The meeting went well, at least form our 
> > perspective.
> > 
> > The pain points we identified were:
> > 
> > * bug mountain
> > 
> > * help users on the mailing list
> > 
> > * patch / MR handling process
> > 
> > * move out of SourceForge
> > 
> > * clean up headers in /include/net-snmp/system/ which are a mess and 
> > have import loops
> > 
> > * #ifdef hell / too many supported configurations
> > 
> > Keith is currently focused on streamlining the process of handling merge 
> > requests, which will make it easier to handle the bug mountain. I will 
> > probably be focusing on the headers for now in hopes that it will make 
> > other processes easier as well. We can help on the repo move whenever 
> > y'all are ready to pull the trigger on that.
> 
> Should a list of to-do items be added to the Net-SNMP wiki?

I think a to-do wiki page on github would be a good idea to deal with what 
needs to be done. Then, as each item is tackled we should have a wiki page that 
details the requirement for each list item. 

> 
> Also, how about adding the following item to the above list: getting rid 
> of 'makedepend' for generating dependency files. Makedepend is 
> considered deprecated and does not work properly on modern systems. Any 
> build system that supports dependency generation is a possible 
> alternative (automake, cmake, ...). See also 
> https://en.wikipedia.org/wiki/Makedepend and 
> https://bugs.freedesktop.org/show_bug.cgi?id=10021.

I think this can be dealt with as part of migrating from autotools to cmake. I 
would also suggest looking into rolling in the #ifdef hell; as cmake can be 
used to deal with the things that #ifdef is dealing with.
 
> 
> Bart.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

Wes,

On Thu, May 10, 2018, at 4:12 PM, Wes Hardaker wrote:
> Keith Mendoza <ke...@icei.org> writes:
> 
> > I would very much like to be part of the discussion regarding moving
> > to Github if its amenable to you guys.
> 
> Sorry for the delay on this; I had a week and a half of constant special
> meetings that took me away from mail.

I appreciate you getting back to this conversation. I sent my 
suggestions/thoughts regarding the github move to the appropriate thread. I'm 
very excited for the new season of Net-SNMP.

> 
> I'm going to post an announcement to -coders here in a few minutes with
> the status and it will ask for feedback.  Please feel free to give
> opinions!
> 
> > In my opinion a discussion forum is the best alternative to a mailing
> > list system.
> 
> Yeah, and that's where we can't please everyone.  I absolutely
> (personally) hate forum systems.  They're not threaded (sometimes to 1
> level), hard to track, hard to tell what's new, hard to catch up on,
> etc.

I agree that we can't please everyone. I think we'll just have to put it to the 
community for a vote should SF give the mailing list hte pink slip.

> 
> -- 
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP is moving to GitHub -- Your input appreciated

[Keith Mendoza]

On Fri, May 11, 2018, at 1:59 AM, Josef Ridky wrote:
> Hi,
> 
> here are my 0.02$
> 
> | 
> | We have decided to move our Net-SNMP development to GitHub after many
> | wonderful years being hosted at SourceForge.  We greatly appreciate
> | SourceForge's support of open source projects over the years, but it's
> | time we take advantage of some features of GitHub that are unique and
> | should help us interact better with the community.  In particular, we
> | hope that GitHub's issues and pull system will allow us to more
> | flexibility in opening up development to more rapid integration by the
> | wider community.
> | 
> 
> Huge THANK YOU.
> 
> | * Things to consider
> | 
> |   1. code base
> |  - This is the easist task as git is decentralized.  The new
> |codebase location is already up at:
> | 
> |  https://github.com/net-snmp/net-snmp
> | 
> |  One question about the code base is outstanding that we have not
> |  yet discussed enough to come to a conclusion about: whether we'll
> |  continue handling patches and forward pushes in the same way (IE,
> |  applying patches to the earliest supported branch and rolling
> |  them forward using merges).  Stay tuned, or better yet, offer
> |  your opinion.  Note that we've had great success with the merging
> |  mechanism as it has ensured us that no patch gets lost in an
> |  older version and that all patches are applied everywhere.  It's
> |  not the only way to do things though, but not losing patches
> |  while supporting older branches is an important feature
> |  consideration.

I would suggest following git accepted practice and go the other way around. 
New code goes to master branch first and the supported branch will only be used 
in cases that a "patch release" (i.e a 5.8.1) is needed.  If the log graph 
looks something like this:

master|commit A||commit B|
  \
supported_release|commit C||commit D|

It should reduce the "merge..." commits since there's a better chance that 
merging from master to the  supported_release branch will be a fast-forward. 
This should also help keep push requests clean as there would be a better 
chance that the master branch of a fork of the net-snmp repo can easily 
fast-forward before they send in their push request.

In order for this to work well, I would suggest changing the release 
procedure/policy. We should focus on getting point releases out more often--say 
maybe once every 3 months at the extreme--and leaving patch releases to cases 
where a functionality inadvertently got broken and its now a complete 
show-stopper. If there's a workaround (short of maybe requiring a cronjob to 
restart snmpd every night) then they can wait for the next point release.

Distro/OS package managers, I'm going to turn the spotlight on you guys for a 
bit. What I would ask of you guys is let the Net-SNMP team know what Net-SNMP 
version you are providing for the OS version that you are supporting. Also, let 
the team know when that OS version has gone out of support. I feel it'll make 
it easier for the dev team to decide when to cut support for  a particular 
Net-SNMP version. I'm more than happy to generate and maintain this matrix for 
the Net-SNMP team once we start receiving this information.

> | 
> |   2. issues/bugs/patches
> | 
> |  This is one that we'd love feedback on.  Our choices are something
> |  along the lines of:
> | 
> |  a. start from scratch and don't move anything?
> |  b. start from bugs after a certain date, figuring the oldest are
> |  likely out of date
> |  c. see if someone has written a SF -> github issue mover
> 
> I am for option B. I think, that issues/bugs older than e.g. 5 years 
> could be omitted. 
> For patches, I think i will be better to go thru all of them, due 
> sometimes, there could be some useful idea that could help to improve 
> this project.

I'm for option A on this one. 5.8's pending release would put it 3 years after 
the 5.7.3 release. I we close off the bug tracker in SF, and new bugs are filed 
in github against 5.8.

I feel that options B and C will need to be tied together, and will require 
someone to go through and disposition what tickets will need to be moved.

> 
> | 
> |   3. website
> | 
> |  Move the primary website to netsnmp.github.io (with the
> |  http://www.net-snmp.org/ domain name continuing to work of course).
> | 
> 
> +1
> 
> |   4. wiki
> | 
> |  Our plan at this point is to convert wiki text to markdown so we
> |  can move it over to github.  This is currently being worked on and
> |  we expect it will be "mostly" successful.
> | 
> |   5. mailing lists
> | 
> |  This is one of the hardest topics.  We've used the SF based mailing
> |  lists for years and they've been one of the strongest aspects of
> |  the Net-SNMP community.  We may pick one of:
> | 
> |  a. Leave the mailing lists at SourceForge
> |  b. 

Re: [PATCH 2/2] inpt_queue changed from CIRCLEQ to TAILQ in OpenBSD 5.6

[Keith Mendoza]

I feel that Net-SNMP should follow what the OS maintainers are willing to 
support. If they're saying they're only going back 2 versions; I strongly urge 
the team to cut the support for them loose. I understand the team's desire to 
maintain backwards compatibility; however, we have to consider the baggage the 
project is taking on here. At the very least, there's code sitting around for 
systems that may not be in use anymore. Worst case, Net-SNMP drags OpenBSD 
along because of a newsworthy vulnerability.

Now, in the spirit of spreading the responsibility wealth I would also ask that 
distro maintainers also do their share and submit patches to remove code 
specifically made for a distro version that's not supported anymore.

On Fri, May 4, 2018, at 9:01 AM, Stuart Henderson wrote:
> On 2018/05/04 10:37, Robert Story wrote:
> > On Fri, 4 May 2018 13:58:43 +0100 Stuart wrote:
> > SH> This is needed for OpenBSD 5.6+. It does break older versions
> > SH> but 5.6 was released in 2014 and support for this ended Oct
> > SH> 2015; I'd find it unlikely that anyone still running this would
> > SH> be building up-to-date net-snmp.
> > 
> > We try really hard to maintain backwards compatibility. Any chance
> > you could throw in a configure test and some ifdefs?
> 
> Personally I think it's a disservice to users to enable them to run
> with such an old version of OpenBSD - there's a 2-release cutoff for
> important fixes in the base OS and 6 months at the most for security
> fixes in ports - we [OpenBSD] don't have the ecosystem where an OS
> vendor provides many years of support and backports for an older major
> version as is the case with some Linux distros.
> 
> But I'd very much like to cut down the amount of patching we have
> to do in the port, so if you really need that I'll take a look :-)
> 
> I'm not good enough at autoconf wrangling to come up with a feature test
> to figure out whether it's using CIRCLEQ or TAILQ. If it's necessary to
> support this then the simplest way to cope is probably to condition on
> OpenBSD >= 201411 (defined in sys/param.h), would that be acceptable?
> 
> (The current mechanism used for version selection in net-snmp doesn't
> fit OpenBSD's release numbering; there are no "major releases", a change
> in the first digit of a release indicates only the passing of time,
> but that doesn't seem like something good to poke at during your rc
> cycle).
> 
> Thanks.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Problem with Crypto - OpenSSL 1.1.0f - Linux 9.4 (stretch)

[Keith Mendoza]

Dave,

On Thu, May 3, 2018, at 2:02 PM, Dave C wrote:
> Thanks, you solved my problem but with the path as /usr/local where I had
> installed openssl to.

Glad I could help. Since you said you were running Raspbian I assumed that you 
used the OpenSSL Debian packages which usually installs in /usr.

> 
> 
> I'll probably have to stick with  5.7.3 for production for now (on Pi
> Compute Module) but seeing as you did me a favour I thought I would give
> 5.8 pre3 a spin for you. Perhaps I'm the first as I just got the release
> notice this morning.
> 
> All worked fine no issues to report, basic tests of my AgentX daemon (still
> compiled against 5.7.3) works.

Appreciate the feedback. I know the dev team would like it to be tested on as 
many hardware/OS platforms as possible.

> 
> 
> ./configure --with-defaults --with-ldflags=-Bstatic --disable-embedded-perl
> > --disable-perl-cc-checks --without-perl-modules --with-openssl=/usr/local
> 
> 
> 
> -
> > Net-SNMP configuration summary:
> > -
> >   SNMP Versions Supported:1 2c 3
> >   Building for:   linux
> >   Net-SNMP Version:   5.8.pre3
> >   Network transport support:  Callback Unix Alias TCP UDP TCPIPv6 UDPIPv6
> > IPv4Base SocketBase TCPBase UDPIPv4Base UDPBase IPv6Base
> >   SNMPv3 Security Modules: usm
> >   Agent MIB code:default_modules =>  snmpv3mibs mibII ucd_snmp
> > notification notification-log-mib target agent_mibs agentx disman/event
> > disman/schedule utilities host
> >   MYSQL Trap Logging: unavailable
> >   Embedded Perl support:  disabled
> >   SNMP Perl modules:  disabled
> >   SNMP Python modules:disabled
> >   Crypto support from:crypto
> >   Authentication support: MD5 SHA1 SHA512 SHA384 SHA256 SHA192
> >   Encryption support: DES AES
> >   Local DNSSEC validation:disabled
> > -
> 
> 
> 
> root@raspberrypi:~# snmpd --version
> > NET-SNMP version:  5.8.pre3
> > Web:   http://www.net-snmp.org/
> > Email: net-snmp-coders@lists.sourceforge.net
> > root@raspberrypi:~# Hello from Pi-land
> 
> 
> 
> 
> 
> On Fri, May 4, 2018 at 1:17 AM, Keith Mendoza <ke...@icei.org> wrote:
> 
> > Dave,
> > Try adding --with-openssl=/usr in the call to configure on your raspberry
> > pi. If you're brave you can also try 5.8pre3  from
> > https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-pre-releases/
> >
> > --
> > Thanks,
> > Keith (pantherse)
> >
> > On Wed, May 2, 2018, at 7:04 PM, Dave C wrote:
> > > I'm trying to build net-snmp-5.7.3 on a raspbery pi running Raspbian 9.4
> > > stretch.
> > >
> > > The default packages are OpenSSL 1.1.0f  25 May 2017, libssl-dev
> > > 1.1.0f-3+deb9u2.
> > >
> > > I configure net-snmp like so,
> > >
> > > ./configure --with-defaults --with-ldflags=-Bstatic
> > --disable-embedded-perl
> > > --disable-perl-cc-checks --without-perl-modules
> > >
> > > And get this config output..
> > >
> > > > -
> > > > Net-SNMP configuration summary:
> > > > -
> > > >   SNMP Versions Supported:1 2c 3
> > > >   Building for:   linux
> > > >   Net-SNMP Version:   5.7.3
> > > >   Network transport support:  Callback Unix Alias TCP UDP IPv4Base
> > > > SocketBase TCPBase UDPIPv4Base UDPBase
> > > >   SNMPv3 Security Modules: usm
> > > >   Agent MIB code:default_modules =>  snmpv3mibs mibII
> > ucd_snmp
> > > > notification notification-log-mib target agent_mibs agentx disman/event
> > > > disman/schedule utilities host
> > > >   MYSQL Trap Logging: unavailable
> > > >   Embedded Perl support:  disabled
> > > >   SNMP Perl modules:  disabled
> > > >   SNMP Python modules:disabled
> > > >   Crypto support from:crypto/ internal ??
> > > >   Authentication support: MD5 SHA1
> > > >   Encryption support: DES AES
> > > >   Local DNSSEC validation:disabled
> > >
> > >
> > > However make dies at this point.
> > >
&

Re: Problem with Crypto - OpenSSL 1.1.0f - Linux 9.4 (stretch)

[Keith Mendoza]

Dave,
Try adding --with-openssl=/usr in the call to configure on your raspberry pi. 
If you're brave you can also try 5.8pre3  from 
https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-pre-releases/

-- 
Thanks,
Keith (pantherse)

On Wed, May 2, 2018, at 7:04 PM, Dave C wrote:
> I'm trying to build net-snmp-5.7.3 on a raspbery pi running Raspbian 9.4
> stretch.
> 
> The default packages are OpenSSL 1.1.0f  25 May 2017, libssl-dev
> 1.1.0f-3+deb9u2.
> 
> I configure net-snmp like so,
> 
> ./configure --with-defaults --with-ldflags=-Bstatic --disable-embedded-perl
> --disable-perl-cc-checks --without-perl-modules
> 
> And get this config output..
> 
> > -
> > Net-SNMP configuration summary:
> > -
> >   SNMP Versions Supported:1 2c 3
> >   Building for:   linux
> >   Net-SNMP Version:   5.7.3
> >   Network transport support:  Callback Unix Alias TCP UDP IPv4Base
> > SocketBase TCPBase UDPIPv4Base UDPBase
> >   SNMPv3 Security Modules: usm
> >   Agent MIB code:default_modules =>  snmpv3mibs mibII ucd_snmp
> > notification notification-log-mib target agent_mibs agentx disman/event
> > disman/schedule utilities host
> >   MYSQL Trap Logging: unavailable
> >   Embedded Perl support:  disabled
> >   SNMP Perl modules:  disabled
> >   SNMP Python modules:disabled
> >   Crypto support from:crypto/ internal ??
> >   Authentication support: MD5 SHA1
> >   Encryption support: DES AES
> >   Local DNSSEC validation:disabled
> 
> 
> However make dies at this point.
> 
> /bin/bash ../libtool  --mode=compile gcc -I../include -I.
> >  -I../snmplib  -fno-strict-aliasing -g -O2 -Ulinux -Dlinux=linux  -c -o
> > keytools.lo keytools.c
> > libtool: compile:  gcc -I../include -I. -I../snmplib -fno-strict-aliasing
> > -g -O2 -Ulinux -Dlinux=linux -c keytools.c  -fPIC -DPIC -o .libs/keytools.o
> > keytools.c: In function 'generate_Ku':
> > keytools.c:155:25: error: dereferencing pointer to incomplete type
> > 'EVP_MD_CTX {aka struct evp_md_ctx_st}'
> >  ctx = malloc(sizeof(*ctx));
> >  ^~~~
> > keytools.c:265:9: warning: implicit declaration of function
> > 'EVP_MD_CTX_cleanup' [-Wimplicit-function-declaration]
> >  EVP_MD_CTX_cleanup(ctx);
> >  ^~
> > Makefile:98: recipe for target 'keytools.lo' failed
> > make[1]: *** [keytools.lo] Error 1
> > make[1]: Leaving directory '/root/net-snmp-5.7.3/snmplib'
> > Makefile:656: recipe for target 'subdirs' failed
> > make: *** [subdirs] Error 1
> 
> 
> So the first question is what's wrong with the above ?
> 
> 
> I have an Ubuntu box where I build net-snmp fine with crypo, it runs
> OpenSSL 1.0.2g so I downgraded the Raspbery PI to 1.0.2o
> 
> apt-get remove openssl
> > apt-get remove libssl-dev
> > cd ~
> > wget https://www.openssl.org/source/openssl-1.0.2o.tar.gz
> > cd openssl...
> > ./config --prefix=/usr/local --openssldir=/usr/local/openssl shared
> > make
> > make install
> > ldconfig
> > ldd $(which openssl)
> > linux-vdso.so.1 (0x7ee91000)
> > /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f09000)
> > libssl.so.1.0.0 => /usr/local/lib/libssl.so.1.0.0 (0x76ea4000)
> > libcrypto.so.1.0.0 => /usr/local/lib/libcrypto.so.1.0.0
> > (0x76d17000)
> > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76d04000)
> > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76bc5000)
> > /lib/ld-linux-armhf.so.3 (0x76f1f000)
> >
> 
> Everything seems fine but now the configuration summary shows only "Crypto
> support from: Internal"
> 
> I looked at the configure script to see how it tests for OpenSSL support
> and replicated that
> 
> #include 
> > char EVP_md5 ();
> > int main(int argc, char *argv[]) {
> >   return EVP_md5 ();
> >   ;
> >   return 0;
> > }
> 
> 
> When I build that I get the following error showing that the EVP_md5 is
> accessible and the crypto library is installed.
> 
> # gcc t.c -lcrypto
> > t.c:3:6: error: conflicting types for ‘EVP_md5’
> >  char EVP_md5 ();
> >   ^~~
> > In file included from /usr/local/include/openssl/x509.h:73:0,
> >  from /usr/local/include/openssl/ssl.h:156,
> >  from t.c:1:
> > /usr/local/include/openssl/evp.h:716:15: note: previous declaration of
> > ‘EVP_md5’ was here
> >  const EVP_MD *EVP_md5(void);
> >^~~
> 
> 
> 
> I'm not sure if that's the exact test that the configure script is doing
> but it's just not detecting
> 
> I hacked the configure script to force CRYPTO="crypto" but then compilation
> fails elsewhere so I assume I actually have installed OpenSSL incorrectly.
> 
> But ether-way I would prefer to fix the first problem above and link
> to  libssl-dev
> 1.1.0f
> 
> Thanks
> 

Re: DISMAN PING MIB test case question

[Keith Mendoza]

On Sun, Apr 29, 2018, at 9:20 AM, Bill Fenner wrote:
> On Fri, Apr 27, 2018 at 12:15 PM, Keith Mendoza <ke...@icei.org> wrote:
> 
> > Bill,
> >
> > On Thu, Apr 26, 2018, at 6:54 PM, Bill Fenner wrote:
> > > I do not think the DISMAN PING module builds anywhere but Linux.  I am
> > not
> > > a fan of the existing implementation since it is synchronous.
> >
> > Would it be worth it to update RUNFULLTEST or T154dismanpingmib_simple to
> > only run on Linux?
> >
> 
>  T154dismanpingmib_simple runs if the module is compiled in (e.g.,
> --with-mib-modules=disman/ping), which it isn't by default.

After I checked-out the v5.8pre3 tag, and ran autoreconf and configure 
--enable-blumenthal-aes --with-defaults --with-openssl=; I went ahead and took a closer look at the configuration summary. I 
spotted the following items in "Agent MIB code": disman/event disman/schedule

I'll double-check if these 2 are actually enabling T154dismanpingmib_simple and 
get back to the group with what I find.

> 
>   Bill

Now, regarding rerunning autoreconf: When I run this git reports that 
aclocal.m4 and configure are modified.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: DISMAN PING MIB test case question

[Keith Mendoza]

After looking further into what's going on with T154_dismanpingmib_simple, I 
discovered that the test script checks if the UID is 0 before it checks if 
disman/ping was enabled. 
https://sourceforge.net/p/net-snmp/code/merge-requests/16/ reorders the check 
to prevent any confusion when the module is not enabled at all.

On Mon, Apr 30, 2018, at 9:11 AM, Keith Mendoza wrote:
> 
> 
> On Sun, Apr 29, 2018, at 9:20 AM, Bill Fenner wrote:
> > On Fri, Apr 27, 2018 at 12:15 PM, Keith Mendoza <ke...@icei.org> wrote:
> > 
> > > Bill,
> > >
> > > On Thu, Apr 26, 2018, at 6:54 PM, Bill Fenner wrote:
> > > > I do not think the DISMAN PING module builds anywhere but Linux.  I am
> > > not
> > > > a fan of the existing implementation since it is synchronous.
> > >
> > > Would it be worth it to update RUNFULLTEST or T154dismanpingmib_simple to
> > > only run on Linux?
> > >
> > 
> >  T154dismanpingmib_simple runs if the module is compiled in (e.g.,
> > --with-mib-modules=disman/ping), which it isn't by default.
> 
> After I checked-out the v5.8pre3 tag, and ran autoreconf and configure 
> --enable-blumenthal-aes --with-defaults --with-openssl= OpenSSL install>; I went ahead and took a closer look at the 
> configuration summary. I spotted the following items in "Agent MIB 
> code": disman/event disman/schedule
> 
> I'll double-check if these 2 are actually enabling 
> T154dismanpingmib_simple and get back to the group with what I find.
> 
> > 
> >   Bill
> 
> Now, regarding rerunning autoreconf: When I run this git reports that 
> aclocal.m4 and configure are modified.
> 
> -- 
> Thanks,
> Keith (pantherse)


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Verify AES support when Blumenthal draft is enabled

[Keith Mendoza]

On Fri, Apr 27, 2018, at 11:00 PM, Keith Mendoza wrote:
> > 
> > Regardless, configure should be doing the right thing based on what
> > is currently installed.
> > 
> > BVA> Regarding your pull request:
> > BVA> I'd like to avoid adding AC_CHECK_HEADERS() calls in
> > BVA> config_project_with_enable because whether or not these
> > BVA> succeed depend on the compiler flags (-I) and some compiler
> > BVA> flags are only set at a later phase.
> > 
> > I agree that header checks inside a feature check is undesirable.
> > Keith, do you think you could come up with a patch that re-arranges
> > configure checks that that the desired effect is achieved?
> 
> Let me give this another go. I think the best solution is when --with-
> openssl is processed that a variable like "blumenthalcapable" be set 
> based on whether the AES-related functions and headers are available. 
> This will also open it up to other configuration checks that may need 
> the same things.

https://sourceforge.net/p/net-snmp/code/merge-requests/14/ has my proposed 
changes.

> 
> > 
> > Robert
> 
> 
> -- 
> Thanks,
> Keith (pantherse)


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Verify AES support when Blumenthal draft is enabled

[Keith Mendoza]

On Fri, Apr 27, 2018, at 2:40 PM, Robert Story wrote:
> On Wed, 25 Apr 2018 10:28:59 -0600 Bart wrote:
> BVA> On 04/25/18 10:04, Keith Mendoza wrote:
> BVA> > I have submitted a merge request to verify that when the
> BVA> > --enable-blumenthal-aes is used in configure that it checks
> BVA> > that OpenSSL's aes.h and evp.h are available. Merge request
> BVA> > is at
> BVA> > https://sourceforge.net/p/net-snmp/code/merge-requests/14/.
> BVA> > [...]
> BVA> 
> BVA> Hello Keith,
> BVA> 
> BVA> Are you aware that running something like "brew upgrade
> BVA> openssl" brings in a version of openssl on OS/X that is recent
> BVA> enough for all Net-SNMP features?
> 
> Regardless, configure should be doing the right thing based on what
> is currently installed.
> 
> BVA> Regarding your pull request:
> BVA> I'd like to avoid adding AC_CHECK_HEADERS() calls in
> BVA> config_project_with_enable because whether or not these
> BVA> succeed depend on the compiler flags (-I) and some compiler
> BVA> flags are only set at a later phase.
> 
> I agree that header checks inside a feature check is undesirable.
> Keith, do you think you could come up with a patch that re-arranges
> configure checks that that the desired effect is achieved?

Let me give this another go. I think the best solution is when --with-openssl 
is processed that a variable like "blumenthalcapable" be set based on whether 
the AES-related functions and headers are available. This will also open it up 
to other configuration checks that may need the same things.

> 
> Robert


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Fri, Apr 27, 2018, at 7:53 PM, Wes Hardaker wrote:
> Robert Story  writes:
> 
> |> That discussion is going on over on our admin list. It's not just a
> |> few of us running amok. ;-)

First, I meant no disrespect when I said "I think it would be best to get full 
agreement from the team on this." My apologies if my statement came across that 
way. 

> 
> Specifically, there are a bunch of pieces that we're considering
> individually.  We'll definitely move the repository, we're definitely
> going to start sending new issues over there.  There is debate about
> what to do with the old issues...  Many are out of date.  Bill Fenner is
> looking into converting the wiki pages to markdown.  etc...  We don't
> have an alternative to the SF mailing lists, though hosting them could
> be done in an number of places but email lists isn't really the way of
> github.  For now we'll leave them on sourceforge.  But under sourceforge
> we can no longer extract all the email addresses to move them, so it'll
> require manual process by everyone subscribed if we do move them.  We'd
> be happy to hear about any other thoughts you have about other
> considerations.  We are deliberately waiting until after 5.8 gets out
> the door to move anything, but our 5.8 announcement will include text
> about the upcoming changes.

I would very much like to be part of the discussion regarding moving to Github 
if its amenable to you guys. As for the old issues, Ian and I suggested 
closing/dropping bugs created before 2012 Nov 8 mainly because of the bug's age 
and the modify on those seem to be a side effect of possibly some activity from 
Sourceforge's infrastructure.

I'm personally split about what should be done the mailing lists. I find it 
convenient because it's email that lands in your inbox with your other emails. 
But, I feel figure out where the conversation has gone so far may require going 
to the mailing list archive a disadvantage. In my opinion a discussion forum is 
the best alternative to a mailing list system. Unfortunately, GIthub doesn't 
have a "discussion forum" system, and users have been begging for it (see 
https://github.com/dear-github/dear-github/issues/44 but I won't hold my breath 
on this one).

What I would add to the list is having a discussion on the following and target 
having a process in place before the "grand opening" to Github:
* "issues" that would normally go on a "discussion forum" if Github had one.
* Whether to stay with the current process of applying changes in the current 
release branch and master.
* How merge requests will be processed.

> 
> -- 
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: ifPhysAddress address is displaying wrong data

[Keith Mendoza]

On Fri, Apr 27, 2018, at 9:05 PM, Venkateswarlu Konamki wrote:
> Hi Robert,
> 
> Iam running snmpd on my ARM embedded device. Since memory is important so i
> can't load any extra mibs into it. Any further solition ?

You have to load the MIB on the machine where you're running snmpget. Here's 
the tutorial on how to load a MIB: 
http://net-snmp.sourceforge.net/wiki/index.php/TUT:Using_and_loading_MIBS

> 
> 
> 
> Thanks,
> 
> Venkateswarlu.K
> 
> On Sat, Apr 28, 2018 at 4:02 AM, Robert Story  wrote:
> 
> > On Fri, 27 Apr 2018 20:08:19 +0530 Venkateswarlu wrote:
> > VK> I am facing one issue with snmp. While fecting the
> > VK> ifPhysAddress for my device interfaces, one of the mac address
> > VK> is displaying wrong data.
> > VK>
> > VK> Version : 5.7.3
> > VK> OS: armv7l GNU/Linux
> > VK>
> > VK> One of my ineterface is having mac address of 24:79:2A:0D:72:48.
> > VK>
> > VK> While fetching the this MAC address for my interface it is
> > VK> giving wrong data.
> > VK>
> > VK> snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3
> > VK>
> > VK> rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y*
> > VK>
> > VK> I didn't get any clue so far. Cam someone help ?
> >
> > Try loading the MIBs, which tell snmpget how to properly display
> > the data returned by the agent.
> >
> >   snmpget -m ALL -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3
> >
> > Robert
> >
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: DISMAN PING MIB test case question

[Keith Mendoza]

Bill,

On Thu, Apr 26, 2018, at 6:54 PM, Bill Fenner wrote:
> I do not think the DISMAN PING module builds anywhere but Linux.  I am not
> a fan of the existing implementation since it is synchronous.

Would it be worth it to update RUNFULLTEST or T154dismanpingmib_simple to only 
run on Linux?

> 
> (I have a from-scratch asynchronous rewrite sitting around languishing that
> I haven't tested anywhere but Linux; raw sockets are pretty notoriously
> incompatible across OSes.  It needs a bit of cleanup and support for
> sending/receiving IPv6 packets...)

Maybe we can revisit this code after 5.8 is released?

> 
>   Bill
> 
> 
> On Thu, Apr 26, 2018 at 2:01 PM, Keith Mendoza <ke...@icei.org> wrote:
> 
> > I have a question about what permissions DISMAN PING MIB test case
> > expects. I'm running on a macOS 12.3.4 with --enable-blumenthal-aes
> > --with-openssl= --with-defaults. When I
> > run make test as my normal user I get "skipped: Not permitted to create raw
> > sockets". However, when I run make test using "sudo make test" I instead
> > get "skipped: USING_DISMAN_PING_MIB_MODULE is not defined". Should I be
> > running "make test" as root?
> >
> > --
> > Thanks,
> > Keith (pantherse)
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Net-snmp-coders mailing list
> > Net-snmp-coders@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
> >


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: ifPhysAddress address is displaying wrong data

[Keith Mendoza]

On Fri, Apr 27, 2018, at 7:38 AM, Venkateswarlu Konamki wrote:
> HI,
> 
> I am facing one issue with snmp. While fecting the  ifPhysAddress for my
> device interfaces, one of the mac address is displaying wrong data.
> 
> Version : 5.7.3
> OS: armv7l GNU/Linux

Can you please provide more information on the Linux distro you're running.

> 
> One of my ineterface is having mac address of 24:79:2A:0D:72:48.
> 
> While fetching the this MAC address for my interface it is giving wrong
> data.
> 
> snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3
> 
> rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y*

Can you provide the full output from snmpget, and please provide the version of 
Net-SNMP that you are running.

> 
> 
> I didn't get any clue so far. Cam someone help ?
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

DISMAN PING MIB test case question

[Keith Mendoza]

I have a question about what permissions DISMAN PING MIB test case expects. I'm 
running on a macOS 12.3.4 with --enable-blumenthal-aes --with-openssl= --with-defaults. When I run make test as my normal 
user I get "skipped: Not permitted to create raw sockets". However, when I run 
make test using "sudo make test" I instead get "skipped: 
USING_DISMAN_PING_MIB_MODULE is not defined". Should I be running "make test" 
as root?

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

5.8 testing status

[Keith Mendoza]

Just want to see where everyone is regarding 5.8 release. Other than what's 
listed in the 5.8pre2 announcement are there any other features that will go 
into 5.8?

Other that the bugs I filed last week from running the test suite against 
master branch, are there any bugs that are part of 5.8?

Do we need to do a 5.8pre3? If so, when is that expected?

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Wed, Apr 25, 2018, at 12:08 PM, Robert Story wrote:
> On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
> IB> This morning we (Keith, Ian) met with an assortment of the
> IB> NET-SNMP developers / contributors (primarily Bart Van Assche)
> IB> to discuss how we could best help the project. The meeting went
> IB> well, at least form our perspective.
> 
> I'm sorry I missed this meeting. I'm almost always on IRC, but
> sometimes go a while without checking the mailing list.
> 
> IB> The pain points we identified were:
> IB> 
> IB> * bug mountain
> IB> * help users on the mailing list
> IB> * patch / MR handling process
> 
> Yep, those are biggies.
> 
> IB> * move out of SourceForge
> 
> We've had recent discussions on this, and I think we'll be moving
> the source to github in the near future.

I think it would be best to get full agreement from the team on this. I hear 
bits-and-pieces that there have been some move in that direction. However, I 
think there should be a separate discussion just on that topic and what it 
would entail to officially move the Net-SNMP project over.

> 
> IB> * clean up headers in /include/net-snmp/system/ which are a
> IB> mess and have import loops
> IB> 
> IB> * #ifdef hell / too many supported configurations
> 
> I'm a little nervous about these one, especially with folks that are
> new to the code base. And as far as supported configurations, we're
> very big on backwards compatibility.
> 
> As 5.8 is getting really close to going out the door, this type of
> cleanup likely won't make it into that release.

Agree completely on both points. I feel that this project should be done by a 
group that's composed by those who know the code, and those new to the code. 
That way, we have assurance that things are not being dropped on the floor on 
accident and that a good knowledge transfer happens. I would go so far as to 
suggest that one member of this "team" should be tasked with documenting what's 
going on; essentially appoint a project librarian if you will.

One conversation I was a part of regarding the configuration is to modularize 
things better and leverage the build system to decide what source files will be 
included in the build based on the target system/configuration. I personally 
would suggest holding this off until we've moved to github.
 
> 
> 
> Got any cmake experts? One of the planned items for 5.9 is moving
> to cmake. The bulk of the work is done (patches from VMware against
> 5.7), but work will be needed to integrate to master and put on the
> finishing touches.

I have experience using cmake, and I'm sure I can tap other people if need be. 
I would suggest that we look into whether the cmake move should be part of the 
"#ifdef hell..." clean up. If you can point me to the branch where the 
CMake-related files are currently stored I'll do some research on it once 5.8 
is released.

As far as versioning is concerned; I personally feel if the build system is 
switched to cmake that it should be considered a major release. I feel that 
rolling it to 5.9 may give some package managers a nasty surprise when their 
packaging script suddenly starts breaking.

> 
> Robert
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

There are obviously a lot of irons that are suddenly being considered to be 
thrown in the fire. Would the Net-SNMP team be amenable to either a 
conference/meeting either on IRC, phone, or video chat to develop a long-term 
plan for the project? I have access to systems we can use for a phone or video 
conference.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

[Keith Mendoza]

On Wed, Apr 25, 2018, at 11:05 AM, Bart Van Assche wrote:
> On 04/25/18 11:54, Keith Mendoza wrote:
> > Out of curiosity, do you have a "fork" of Net-SNMP on github to connect it 
> > to Travis and Appveyor?
> 
> Hello Keith,
> 
> If you are looking for a Net-SNMP repository on github, please use 
> https://github.com/net-snmp/net-snmp. I hope Wes will connect that 
> repository to Travis and Appveyor.

Woo hoo. Now if we can plan out what other stuff we want moved from SF.

> 
> Thanks,
> 
> Bart.


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Verify AES support when Blumenthal draft is enabled

[Keith Mendoza]

Bart,

On Wed, Apr 25, 2018, at 9:28 AM, Bart Van Assche wrote:
> On 04/25/18 10:04, Keith Mendoza wrote:
> > Net-SNMP dev team,
> > I have submitted a merge request to verify that when the 
> > --enable-blumenthal-aes is used in configure that it checks that OpenSSL's 
> > aes.h and evp.h are available. Merge request is at 
> > https://sourceforge.net/p/net-snmp/code/merge-requests/14/. This should 
> > fully resolve the following bugs:
> > 
> > * #2859 Test case "T023snmpv3getMD5DES_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2859/)
> > 
> > * #2855 Test case "T026snmpv3getSHAAES_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2855/)
> > 
> > * #2854 Test case "T025snmpv3getSHADES_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2854/)
> > 
> > * #2852 Test case "T024snmpv3getSHA1_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2852/)
> > 
> > This fix provides a partial fix for #2853 Test case 
> > "T024snmpv3getSHA512_simple" fails (#2853 Test case 
> > "T024snmpv3getSHA512_simple" fails). The rest of the fix is Bart's commit 
> > 3c104a.
> 
> Hello Keith,
> 
> Are you aware that running something like "brew upgrade openssl" brings 
> in a version of openssl on OS/X that is recent enough for all Net-SNMP 
> features? 

>From what I know OpenSSL is available through Homebrew or Macports--among 
>others. Apple doesn't seem to provide OpenSSL by themselves. So doing that 
>should upgrade openssl provided the package info for the package manager has 
>been done too.

> Regarding your pull request: I'd like to avoid adding 
> AC_CHECK_HEADERS() calls in config_project_with_enable because whether 
> or not these succeed depend on the compiler flags (-I) and some compiler 
> flags are only set at a later phase.

I agree that placing the AC_CHECK_HEADERS() where it is _not_ the best place 
for it as it assumes that --with-ssl always occurs before 
--enable-blumenthal-aes. I suspect that if the --with-ssl code is moved after 
that the AC_CHECK_HEADERS will always fail. I felt that placing it there would 
be a good starting point; and I figured someone with more experience with the 
codebase will tell me where it should go as a rule-of-thumb for the project.

I feel the best solution would be to remove the typecasts going on inside 
sc_get_openssl_hashfn(). It seems to me that having these typecasts there is 
triggering the implicit declaration of EVP_sha512() that lead to the crash we 
both encountered. However, I don't want testing the "best" solution to block 
5.8 release.

> 
> Thanks,
> 
> Bart.


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

[Keith Mendoza]

Bart,
Out of curiosity, do you have a "fork" of Net-SNMP on github to connect it to 
Travis and Appveyor?

On Wed, Apr 25, 2018, at 8:06 AM, Bart Van Assche wrote:
> Hello,
> 
> One of the advantages of github over SourceForge is that integration 
> with continuous integration (CI) services like Travis and Appveyor is 
> easy. Adding such support however requires to add proper configuration 
> files and the necessary scripts in the source tree. Hence this patch. As 
> one can see for Linux all regression tests are run, for OS/X some 
> regression tests are run and for MSVC and Cygwin no regression tests are 
> run. All four builds pass with this patch. As usual, feedback is welcome.
> 
> Bart.
> 
> 
> ---
>   .appveyor.yml  |  10 +
>   .travis.yml|  35 
>   ci/build.bat   |  30 +++
>   ci/build.sh|  17 ++
>   ci/net-snmp-configure  | 211 +
>   ci/net-snmp-run-perl-tests |   9 +
>   ci/net-snmp-run-python-tests   |  16 ++
>   ci/net-snmp-run-tests  |  37 
>   .../fulltests/default/T200snmpv2cwalkall_simple|   2 +
>   testing/fulltests/support/simple_eval_tools.sh |  21 +-
>   10 files changed, 381 insertions(+), 7 deletions(-)
>   create mode 100644 .appveyor.yml
>   create mode 100644 .travis.yml
>   create mode 100644 ci/build.bat
>   create mode 100755 ci/build.sh
>   create mode 100755 ci/net-snmp-configure
>   create mode 100755 ci/net-snmp-run-perl-tests
>   create mode 100755 ci/net-snmp-run-python-tests
>   create mode 100755 ci/net-snmp-run-tests
> 
> diff --git a/.appveyor.yml b/.appveyor.yml
> new file mode 100644
> index ..137c52052d34
> --- /dev/null
> +++ b/.appveyor.yml
> @@ -0,0 +1,10 @@
> +image:
> +  - Visual Studio 2017
> +environment:
> +  matrix:
> +- BUILD: MSVC
> +# - BUILD: MinGW
> +- BUILD: Cygwin
> +clone_depth: 5
> +build_script:
> +  - 'call "ci\build.bat"'
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index ..7262aa19aab0
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,35 @@
> +language: c
> +
> +os:
> +  - linux
> +  - osx
> +
> +dist: trusty
> +
> +sudo: required
> +
> +addons:
> +  apt:
> +packages:
> +  - dpkg
> +  - gcc
> +  - libatm-dev
> +  - libperl-dev
> +  - libsensors4-dev
> +  - libssh-dev
> +  - libssl-dev
> +  - make
> +  - perl-modules
> +  - pkg-config
> +  - python-dev
> +  - python-setuptools
> +
> +# Add an IPv6 config - see the corresponding Travis issue
> +# https://github.com/travis-ci/travis-ci/issues/8361
> +before_script:
> +  - if [ "${TRAVIS_OS_NAME}" == "linux" ]; then
> +  sudo sh -c 'echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6; 
> printf "\n::1 localhost ipv6-localhost ipv6-loopback\n" >>/etc/hosts; 
> cat /etc/hosts';
> +fi
> +  - 'if [ "${TRAVIS_OS_NAME}" == "osx" ]; then brew upgrade openssl 
>  >/dev/null 2>&1; fi'
> +
> +script: ci/build.sh
> diff --git a/ci/build.bat b/ci/build.bat
> new file mode 100644
> index ..cea6a89a4886
> --- /dev/null
> +++ b/ci/build.bat
> @@ -0,0 +1,30 @@
> +echo "Build type %BUILD%"
> +@echo on
> +goto %BUILD%
> +echo "Error: unknown build type %BUILD%"
> +goto eof
> +
> +:MSVC
> +REM see also https://www.appveyor.com/docs/lang/cpp/
> +REM if exist "C:\Program Files (x86)\Microsoft Visual Studio\2017" (
> +REM   set "d=C:\Program Files (x86)\Microsoft Visual Studio\2017"
> +REM ) else if exist "C:\Program Files\Microsoft Visual Studio\2017" (
> +REM   set "d=C:\Program Files\Microsoft Visual Studio\2017"
> +REM )
> +REM cmd /c ""%d%"\Community\VC\Auxiliary\Build\vcvarsall.bat x86"
> +REM install:
> +call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
> \vcvarsall.bat"
> +cd win32
> +perl Configure --config=release --with-sdk --with-ipv6 --with-winextdll 
> --linktype=dynamic
> +nmake
> +goto eof
> +
> +:MinGW
> +C:\msys64\usr\bin\bash --login -c 'set -x; cd 
> "${APPVEYOR_BUILD_FOLDER}"; ci/build.sh'
> +goto eof
> +
> +:Cygwin
> +c:\cygwin\bin\bash --login -c 'set -x; cd "${APPVEYOR_BUILD_FOLDER}"; 
> ci/build.sh'
> +goto eof
> +
> +:eof
> diff --git a/ci/build.sh b/ci/build.sh
> new file mode 100755
> index ..3e306d82bf17
> --- /dev/null
> +++ b/ci/build.sh
> @@ -0,0 +1,17 @@
> +#!/bin/bash
> +
> +scriptdir="$(dirname "$0")"
> +export NOAUTODEPS=1
> +export SNMP_VERBOSE=1
> +if [ -z "$OSTYPE" ]; then
> +case "$(uname)" in
> +Linux)  OSTYPE=linux;;
> +Darwin) OSTYPE=darwin;;
> +*)  OSTYPE="UNKNOWN:$(uname)";;
> +esac
> +export OSTYPE
> +fi
> +"${scriptdir}"/net-snmp-configure master || exit $?
> +make -s  || exit $?
> +[ "$OSTYPE" = cygwin ]&& exit 0
> +"${scriptdir}"/net-snmp-run-tests

Verify AES support when Blumenthal draft is enabled

[Keith Mendoza]

Net-SNMP dev team,
I have submitted a merge request to verify that when the 
--enable-blumenthal-aes is used in configure that it checks that OpenSSL's 
aes.h and evp.h are available. Merge request is at 
https://sourceforge.net/p/net-snmp/code/merge-requests/14/. This should fully 
resolve the following bugs:

* #2859 Test case "T023snmpv3getMD5DES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2859/)

* #2855 Test case "T026snmpv3getSHAAES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2855/)

* #2854 Test case "T025snmpv3getSHADES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2854/)

* #2852 Test case "T024snmpv3getSHA1_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2852/)

This fix provides a partial fix for #2853 Test case 
"T024snmpv3getSHA512_simple" fails (#2853 Test case 
"T024snmpv3getSHA512_simple" fails). The rest of the fix is Bart's commit 
3c104a.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP v5.8 and Darwin

[Keith Mendoza]

Bart,

On Mon, Apr 23, 2018, at 6:45 AM, Bart Van Assche wrote:
> On 04/23/18 00:34, Keith Mendoza wrote:
> > Even with the -std=c89 flag the issue is still present. I was able to 
> > replicate the issue with the following code:
> > 
> > === BEGIN C CODE ===
> > #include 
> > #define OPENSSL_NO_SHA512
> > #include 
> > 
> > const EVP_MD *getType()
> > {
> >  const EVP_MD *ret;
> >  ret = (const EVP_MD *)EVP_sha512();
> > 
> >  return ret;
> > }
> > 
> > int main()
> > {
> >  EVP_MD_CTX ctx;
> >  const EVP_MD *type = NULL;
> >  int retVal = 0;
> > 
> >  OpenSSL_add_all_digests();
> > 
> >  type = getType();
> >  if(!EVP_DigestInit(, type))
> >  {
> >  fprintf(stderr, "Failed to init digest\n");
> >  retVal = 1;
> >  goto drop;
> >  }
> >  else
> >  printf("Digest initialized\n");
> > 
> > drop:
> >  EVP_cleanup();
> >  return 0;
> > }
> > === END C CODE ===
> > 
> > Note the #define right before #include . The darwin*.h files 
> > that I mention earlier are only referenced in INCLUDESUBDIRHEADERS variable 
> > in net-snmp/Makefile.in file. However, after removing those from the list 
> > and running autoreconf, the warning about EVP_sha512 being undeclared--and 
> > the crash--are all still occurring. The only think I can think of at this 
> > point is some header that has #define OPENSSL_NO_SHA512 is in play 
> > somewhere.
> > 
> > Hope this helps narrow things down.
> 
> Thanks Keith, that helps a lot. Based on this feedback I checked in a 
> new patch on the v5.7 and master branches. With that patch applied all 
> tests pass on Travis for Darwin except the full MIB walk.

I can confirm that T024snmpv3getSHA512_simple now passes for me too. I updated 
bug 2853 accordingly.

However, in addition to the full MIB walk, test T071com2sec6_simple is also 
still failing. I know this is not related to the Darwin crash; just want to 
make sure I provide the complete picture that I'm seeing.

> 
> Bart.


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP v5.8 and Darwin

[Keith Mendoza]

Bart, 

On Sun, Apr 22, 2018, at 4:59 PM, Keith Mendoza wrote:
> Bart,
> I was hoping to discuss with you on IRC; but, you're not online.
> 
> On Sun, Apr 22, 2018, at 4:10 PM, Bart Van Assche wrote:
> > On 04/22/18 08:35, Keith Mendoza wrote:
> > > Bart,
> > > I was actually working on this yesterday. This is what I know so far 
> > > after a few hours of digging into this: It appears that there's an issue 
> > > with getting to the memory address that EVP_sha512() returns when it's 
> > > called in sc_get_openssl_hashfn(). Why this is so, I don't know. Below 
> > > are details of what I've figured out so far:
> > > 
> > > On my environment, I'm using OpenSSL 1.0.2o installed using mac ports. 
> > > EVP_sha512() simply returns the address of a static const struct 
> > > env_md_st instance once you expand the EVP_MD typedef (see the source 
> > > here: 
> > > https://github.com/openssl/openssl/blob/3ce7bc40a3c48da1c96c2d04c10045bd797c6aa3/crypto/evp/m_sha1.c#L216).
> > >  When I was stepping through using the lldb debugger, when I inspect the 
> > > value of hashfn after the call to EVP_sha512() it actually reports an 
> > > error that the address is inaccessible. That one's got me stumped. In 
> > > line 192, the call EVP_DigestInit() happens and the address returned by 
> > > EVP_sha512() is passed as the 2nd parameter to that function. Kaboom for 
> > > obvious reasons.
> > > 
> > > I'm no expert on the rules of accessing memory space from dynamic 
> > > libraries. Hopefully, someone else can chime in. My next step  is to 
> > > write a small test program to isolate the digest initialization code to 
> > > see if I can replicate the issue outside of Net-SNMP.
> > 
> > Hello Keith,
> > 
> > Can you have a look at the openssl/evp.h header file? The following 
> > warning appears in the OS/X build output, which is suspicious:
> > 
> > 
> > scapi.c:88:12: warning: implicit declaration of function 'EVP_sha224' is 
> > invalid in C99 [-Wimplicit-function-declaration]
> >  return EVP_sha224();
> > ^
> 
> I actually stumbled on include/net-snmp/system/darwin*.h files while 
> figuring out why things are crashes when I thought that EVP_DigestInit() 
> wanted a function pointer. I've used EVP_DigestInit_ex() in the past 
> which would normally pass the address of EVP_*() functions as it's 3rd 
> parameter. Since I wanted to assign the address of the functions in 
> sc_get_openssl_hashfn() I got an undeclared error. Based on the comments 
> on those files it feels like making sure that Net-SNMP doesn't try to 
> use functions that are not present in the OpenSSL version available for 
> the given macOS versions, I feel that should have been a function check 
> in automake and sc_get_openssl_hashfn() whould have #ifdef 
> HAVE_ on them instead.
> 
> On another note, I thought that Net-SNMP has to use C89 thanks to 
> Microsoft deciding they're not going to support anything past that? I 
> feel mixing C versions between targets could cause us maintenance 
> issues.
> 
> > 
> > Thanks,
> > 
> > Bart.
> 
> This is what I'm going to do: I'm going to add --with-cflags='-std=c89' 
> in configureu and see if we stumbled on something that clang does 
> differently with the ABI when its compiling in C99 vs C89.

Even with the -std=c89 flag the issue is still present. I was able to replicate 
the issue with the following code:

=== BEGIN C CODE ===
#include 
#define OPENSSL_NO_SHA512
#include 

const EVP_MD *getType()
{
const EVP_MD *ret;
ret = (const EVP_MD *)EVP_sha512();

return ret;
}

int main()
{
EVP_MD_CTX ctx;
const EVP_MD *type = NULL;
int retVal = 0;

OpenSSL_add_all_digests();

type = getType();
if(!EVP_DigestInit(, type))
{
fprintf(stderr, "Failed to init digest\n");
retVal = 1;
goto drop;
}
else
printf("Digest initialized\n");

drop:
EVP_cleanup();
return 0;
}
=== END C CODE ===

Note the #define right before #include . The darwin*.h files 
that I mention earlier are only referenced in INCLUDESUBDIRHEADERS variable in 
net-snmp/Makefile.in file. However, after removing those from the list and 
running autoreconf, the warning about EVP_sha512 being undeclared--and the 
crash--are all still occurring. The only think I can think of at this point is 
some header that has #define OPENSSL_NO_SHA512 is in play somewhere.

Hope this helps narrow things down.

> 
> -- 
> Thanks,
> Keith (pantherse)


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP v5.8 and Darwin

[Keith Mendoza]

Bart,
I was hoping to discuss with you on IRC; but, you're not online.

On Sun, Apr 22, 2018, at 4:10 PM, Bart Van Assche wrote:
> On 04/22/18 08:35, Keith Mendoza wrote:
> > Bart,
> > I was actually working on this yesterday. This is what I know so far after 
> > a few hours of digging into this: It appears that there's an issue with 
> > getting to the memory address that EVP_sha512() returns when it's called in 
> > sc_get_openssl_hashfn(). Why this is so, I don't know. Below are details of 
> > what I've figured out so far:
> > 
> > On my environment, I'm using OpenSSL 1.0.2o installed using mac ports. 
> > EVP_sha512() simply returns the address of a static const struct env_md_st 
> > instance once you expand the EVP_MD typedef (see the source here: 
> > https://github.com/openssl/openssl/blob/3ce7bc40a3c48da1c96c2d04c10045bd797c6aa3/crypto/evp/m_sha1.c#L216).
> >  When I was stepping through using the lldb debugger, when I inspect the 
> > value of hashfn after the call to EVP_sha512() it actually reports an error 
> > that the address is inaccessible. That one's got me stumped. In line 192, 
> > the call EVP_DigestInit() happens and the address returned by EVP_sha512() 
> > is passed as the 2nd parameter to that function. Kaboom for obvious reasons.
> > 
> > I'm no expert on the rules of accessing memory space from dynamic 
> > libraries. Hopefully, someone else can chime in. My next step  is to write 
> > a small test program to isolate the digest initialization code to see if I 
> > can replicate the issue outside of Net-SNMP.
> 
> Hello Keith,
> 
> Can you have a look at the openssl/evp.h header file? The following 
> warning appears in the OS/X build output, which is suspicious:
> 
> 
> scapi.c:88:12: warning: implicit declaration of function 'EVP_sha224' is 
> invalid in C99 [-Wimplicit-function-declaration]
>  return EVP_sha224();
> ^

I actually stumbled on include/net-snmp/system/darwin*.h files while figuring 
out why things are crashes when I thought that EVP_DigestInit() wanted a 
function pointer. I've used EVP_DigestInit_ex() in the past which would 
normally pass the address of EVP_*() functions as it's 3rd parameter. Since I 
wanted to assign the address of the functions in sc_get_openssl_hashfn() I got 
an undeclared error. Based on the comments on those files it feels like making 
sure that Net-SNMP doesn't try to use functions that are not present in the 
OpenSSL version available for the given macOS versions, I feel that should have 
been a function check in automake and sc_get_openssl_hashfn() whould have 
#ifdef HAVE_ on them instead.

On another note, I thought that Net-SNMP has to use C89 thanks to Microsoft 
deciding they're not going to support anything past that? I feel mixing C 
versions between targets could cause us maintenance issues.

> 
> Thanks,
> 
> Bart.

This is what I'm going to do: I'm going to add --with-cflags='-std=c89' in 
configureu and see if we stumbled on something that clang does differently with 
the ABI when its compiling in C99 vs C89.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP v5.8 and Darwin

[Keith Mendoza]

Bart,
I was actually working on this yesterday. This is what I know so far after a 
few hours of digging into this: It appears that there's an issue with getting 
to the memory address that EVP_sha512() returns when it's called in 
sc_get_openssl_hashfn(). Why this is so, I don't know. Below are details of 
what I've figured out so far:

On my environment, I'm using OpenSSL 1.0.2o installed using mac ports. 
EVP_sha512() simply returns the address of a static const struct env_md_st 
instance once you expand the EVP_MD typedef (see the source here: 
https://github.com/openssl/openssl/blob/3ce7bc40a3c48da1c96c2d04c10045bd797c6aa3/crypto/evp/m_sha1.c#L216).
 When I was stepping through using the lldb debugger, when I inspect the value 
of hashfn after the call to EVP_sha512() it actually reports an error that the 
address is inaccessible. That one's got me stumped. In line 192, the call 
EVP_DigestInit() happens and the address returned by EVP_sha512() is passed as 
the 2nd parameter to that function. Kaboom for obvious reasons.

I'm no expert on the rules of accessing memory space from dynamic libraries. 
Hopefully, someone else can chime in. My next step  is to write a small test 
program to isolate the digest initialization code to see if I can replicate the 
issue outside of Net-SNMP.

Thanks,
Keith

On Sat, Apr 21, 2018, at 8:20 PM, Bart Van Assche wrote:
> Hello,
> 
> Can someone who has access to a Darwin (OS/X) system analyze why test 
> T024snmpv3getSHA512_simple from the master branch triggers a 
> segmentation fault on Darwin? I noticed this while trying to make the 
> Net-SNMP tests pass on Travis. See also 
> https://travis-ci.org/bvanassche/net-snmp/jobs/369646490 for how 
> Net-SNMP was configured and also for the job output.
> 
> Thanks,
> 
> Bart.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Unstable tests

[Keith Mendoza]

Not ideal; but I guess it'll have to do for now.

On Sat, Apr 14, 2018, at 3:56 PM, Bart Van Assche wrote:
> On 04/05/18 16:38, Lee wrote:
> > On 4/5/18, Keith Mendoza  wrote:
> >> So again, at what point do we stop adding code to net-snmp because
> >> ISP's are messing around as if they're doing us a favor by letting us
> >> use their services?
> > 
> > Since people don't read the docs, how about adding a test to see if
> > dns is borked; if it is link to a faq entry for possible ways to fix
> > it.
> > 
> > verizon 'opt out of dns assistance' link:
> >
> > https://www.verizon.com/support/residential/internet/home-network/settings/opt-out-of-dns-assist
> 
> How about the patch below? With this patch applied Net-SNMP developers can
> make the tests pass easily by setting the NETSNMP_DNS_WORKAROUND environment
> variable before running the tests and normal operation of snmpd is not
> affected.
> 
> Thanks,
> 
> Bart.
> 
> 
> 
> Subject: [PATCH] snmplib: Avoid that test T070com2sec_simple fails due 
> to DNS filtering
> 
> ---
>  snmplib/system.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/snmplib/system.c b/snmplib/system.c
> index d7f06f74087f..28b832352247 100644
> --- a/snmplib/system.c
> +++ b/snmplib/system.c
> @@ -762,6 +762,24 @@ netsnmp_validator_context(void)
>  int
>  netsnmp_gethostbyname_v4(const char* name, in_addr_t *addr_out)
>  {
> +if (getenv("NETSNMP_DNS_WORKAROUND")) {
> +/*
> + * A hack that avoids that T070com2sec_simple fails due to the 
> DNS
> + * client filtering out 127.0.0.x addresses and/or redirecting 
> DNS
> + * resolution failures to a web page.
> + */
> +if (strcmp(name, "onea.net-snmp.org") == 0) {
> +*addr_out = htonl(INADDR_LOOPBACK);
> +return 0;
> +} else if (strcmp(name, "twoa.net-snmp.org") == 0) {
> +*addr_out = htonl(INADDR_LOOPBACK + 1);
> +return 0;
> +} else if (strcmp(name, "no.such.address.") == 0) {
> +return -1;
> +}
> +}
> +
> +{
>  #if HAVE_GETADDRINFO
>  struct addrinfo *addrs = NULL;
>  struct addrinfo hint;
> @@ -826,6 +844,7 @@ netsnmp_gethostbyname_v4(const char* name, in_addr_t 
> *addr_out)
>  #else /* HAVE_GETIPNODEBYNAME */
>  return -1;
>  #endif
> +}
>  }
>  
>  int
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Merge request processing

[Keith Mendoza]

Net-SNMP devs,
After a few discussion in IRC, I feel that I have an understanding on why 
project leadership prefers patches over merge request. I would like to 
summarize them here to make sure that my understanding is correct. Patches are 
applied in the master and the current release's branch (at present this is 
v5.7-patch), and local/gittools/shell-functions makes sure that patches are 
applied to both branches, or removed it if the patch application fails in 
either branch. However, in another conversation over IRC I learned that in the 
past code submitted through merge request required significant rework that 
really can't be automated.

To me, SF's merge request mechanism not having an ability to view a diff of 
what's being submitted is frustrating. If I have to do a git fetch just so I 
can run git diff on the changes included in the merge request; I would go "f*** 
it" and just fix issues with the submitted code changes myself. Unfortunately, 
I feel that this is a disservice to the project team and the merge request 
submitter. Now someone just did extra work they didn't need to do, and the 
submitter doesn't have an opportunity to learn from their mistake.

If the team is willing to give merge requests another shot, this is the process 
that I would propose:

1. We instruct contributors what branch they should be using to make their 
changes based on what their code change is for. Bug fixes should go in current 
patch branch; new features go in master.

2. Review the merge request diff by running
git fetch git://git.code.sf.net/
git diff  

3. When all is well, run
git merge  

4. If we don't like what we see do our best to provide feedback to the 
submitter so they can redo their merge request. Unfortunately, SF doesn't 
provide a way to easily point out the lines of codes you found issues with that 
other software forges provides.

I hope this gets the ball rolling in helping streamline the patch 
submission/merge request process. Questions/comments appreciated.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

5.7.4 candidate bugs

[Keith Mendoza]

As I mentioned in the "Summary of meeting between NET-SNMP devs and ICEI" 
thread, here's a list of bugs that I found could be included in a 5.7.4 release.

Comment indicate change is in v5-7-patch branch, and waiting for confirmation 
from submitter
* 2810 Logical error in agent/​helpers/​table.c when --enable-read-only is used 
during configuring

* 2845 compile error with net-snmp-5.8.pre2/agent/snmp_agent.c

* 2846 Second compile error with net-snmp-5.8.pre2/agent/snmp_agent.c

* 2822 5.4 4 segfault with verison 3 and agent restart

* 2791  systemd returns 0 prCount when net-snmpd collect number of running 
processes

Comment indicate change is in v5-7-patch branch, and submitter confirms the fix 
works
* 2550 netsnmp_assert failed message

Comment indicate that the proposed patch in the patch ticket resolves the issue
* 2640 Crash in function ipAddressTable_container_load() (See patch ticket 2589)

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Thu, Apr 12, 2018, at 2:18 PM, Magnus Fromreide wrote:
> On Thu, Apr 12, 2018 at 12:19:35PM -0700, Keith Mendoza wrote:
> > On Thu, Apr 12, 2018, at 10:03 AM, Bill Fenner wrote:
> > > I'm sorry that I wasn't available for this meeting.  I think one important
> > > pain point is the overhead of doing releases - 5.7.3 was years ago and
> > > there are very useful fixes in the 5.7 branch; why can't we just say 
> > > "now's
> > > a good time for 5.7.4 and if we don't get it right then we can release
> > > 5.7.5 soon"?  To be fair, I've never driven a net-snmp release so I don't
> > > know what's involved.
> > 
> > I think from a project morale perspective it will be good to get a 5.7.4 
> > out. > At the very least, it'll show the world that the project is active 
> > (or active
> > again if they choose to see it that way). Is there a working list of what
> > bugs/features are planned for 5.7.4; if so, can that be finalized at this
> > point?
> 
> I think 5.7.4 is just a bugfix release.
> 5.8, of which I think the release process was initiated a while back, is
> a new feature release. I know that I have added a typed value to the perl
> handlers so that you won't have to change a global parameter in the agent to
> get hold of the numeric oid value of an oid-type variable.

I'll go ahead and look through the bugs that are in "Pending" state and compile 
a list of ones that have an indication that it has fixes ready for a  5.7.4. 
When I'm done, I'll send the list in a separate thread; hopefully, that 
provides some visibility of what a 5.4.7 might look like.

> 
> /MF
> 
> > > 
> > >   Bill
> > > 
> > > 
> > > On Thu, Apr 12, 2018 at 11:31 AM, Ian Bruene <ianbru...@icei.org> wrote:
> > > 
> > > >
> > > > This morning we (Keith, Ian) met with an assortment of the NET-SNMP
> > > > developers / contributors (primarily Bart Van Assche) to discuss how we
> > > > could best help the project. The meeting went well, at least form our
> > > > perspective.
> > > >
> > > > The pain points we identified were:
> > > >
> > > > * bug mountain
> > > >
> > > > * help users on the mailing list
> > > >
> > > > * patch / MR handling process
> > > >
> > > > * move out of SourceForge
> > 
> > If a release of 5.7.4 is done in the next month or so, that might also be a 
> > good time to put up the "we're moving" sign. If we can get a few people 
> > whose done this before to get together, coming up with the plan could be 
> > done in parallel with the 5.7.4 work. 
> > 
> > > >
> > > > * clean up headers in /include/net-snmp/system/ which are a mess and 
> > > > have
> > > > import loops
> > > >
> > > > * #ifdef hell / too many supported configurations
> > > >
> > > > Keith is currently focused on streamlining the process of handling merge
> > > > requests, which will make it easier to handle the bug mountain. I will
> > > > probably be focusing on the headers for now in hopes that it will make
> > > > other processes easier as well. We can help on the repo move whenever 
> > > > y'all
> > > > are ready to pull the trigger on that.
> > 
> > I have a few questions for the core team regarding this; expect another 
> > email to the mailing list in a little bit.
> > 

=== snip 

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Thu, Apr 12, 2018, at 10:03 AM, Bill Fenner wrote:
> I'm sorry that I wasn't available for this meeting.  I think one important
> pain point is the overhead of doing releases - 5.7.3 was years ago and
> there are very useful fixes in the 5.7 branch; why can't we just say "now's
> a good time for 5.7.4 and if we don't get it right then we can release
> 5.7.5 soon"?  To be fair, I've never driven a net-snmp release so I don't
> know what's involved.

I think from a project morale perspective it will be good to get a 5.7.4 out. 
At the very least, it'll show the world that the project is active (or active 
again if they choose to see it that way). Is there a working list of what 
bugs/features are planned for 5.7.4; if so, can that be finalized at this point?

> 
>   Bill
> 
> 
> On Thu, Apr 12, 2018 at 11:31 AM, Ian Bruene  wrote:
> 
> >
> > This morning we (Keith, Ian) met with an assortment of the NET-SNMP
> > developers / contributors (primarily Bart Van Assche) to discuss how we
> > could best help the project. The meeting went well, at least form our
> > perspective.
> >
> > The pain points we identified were:
> >
> > * bug mountain
> >
> > * help users on the mailing list
> >
> > * patch / MR handling process
> >
> > * move out of SourceForge

If a release of 5.7.4 is done in the next month or so, that might also be a 
good time to put up the "we're moving" sign. If we can get a few people whose 
done this before to get together, coming up with the plan could be done in 
parallel with the 5.7.4 work. 

> >
> > * clean up headers in /include/net-snmp/system/ which are a mess and have
> > import loops
> >
> > * #ifdef hell / too many supported configurations
> >
> > Keith is currently focused on streamlining the process of handling merge
> > requests, which will make it easier to handle the bug mountain. I will
> > probably be focusing on the headers for now in hopes that it will make
> > other processes easier as well. We can help on the repo move whenever y'all
> > are ready to pull the trigger on that.

I have a few questions for the core team regarding this; expect another email 
to the mailing list in a little bit.

> >
> > --
> > *"In the end; what separates a Man, from a Slave? Money? Power? No. A Man
> > Chooses, a Slave Obeys."* -- Andrew Ryan
> >
> > *"Utopia cannot precede the Utopian. It will exist the moment we are fit
> > to occupy it."* -- Sophia Lamb
> >
> > I work for the Internet Civil Engineering Institute ,
> > help us save the Internet from Entropy!
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Net-snmp-coders mailing list
> > Net-snmp-coders@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
> >
> >
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: IRC chat to help our new guard get on board?

[Keith Mendoza]

net-snmp developers,
Please join us for an IRC chat on #newguard at freenode.net on April
12 5:30 AM PDT/6:30 AM MDT/7:30 AM CDT/8:30 AM EDT/12:30 PM UTC for a
meet-and-greet with ICEI's newguards who wants to contribute to the
net-snmp project.

Looking forward to chatting with you guys.

Thanks,
Keith


On Wed, Apr 4, 2018 at 10:18 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> Keith Mendoza <panthe...@gmail.com>:
>> So far, this is the time that may work for everyone if we do it the
>> week of April 8 (UTC and US time zones): 5:30 AM PDT/6:30 AM MDT/7:30
>> AM CDT/8:30 AM EDT/12:30 PM UTC--6:00 AM PDT/7:00 AM MDT/8:00 AM
>> CDT/9:00 AM EDT/1:00 PM UTC.
>>
>> Eric,
>> How do you feel about having the meeting the week of April 16 to see
>> if we can get better timing and more people to come?
>
> I don't have a preference.  I think you're collecting better information
> to base a decision on than I am.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Some bugs that need closing

[Keith Mendoza]

net-snmp dev team,
Ian and I went through another round of going through the bug lists
for ones that we feel can either be closed, or placed in WONTFIX:
* 1989, 2490, 2101, 1765, 2554: These have proposed patches that
doesn't appear to have been applied.

* 2438: Fixed in patch 1249, which is merged.

* 2462: user had a different version of a library.

* 2327, 2282 2558: These 3 are issues related to the Perl binding
printing messages to STDERR. Patch 1285 as containing the solution.

* 2769: Website has been back up since March 2018 after the migration.

* 2576, 2577: The POC code is suspect to me. Code will never do
snmp_close(); who knows what cleanup is never happening with this not
happening at program termination. At least they didn't
website with a flashy name.

* 2479: Gives screenshot *sigh* but no other info.

* 2429: Not enough info to show that there's indeed a leak.

After going through the list, we feel that any bugs created before
2012 Nov 8 should just be closed/dropped at this point. That way we
can focus our efforts on working on bugs that are left after that
date.

Thanks,
Keith

Thanks,
Keith


On Sun, Apr 1, 2018 at 7:21 AM, Ian Bruene  wrote:
>
>
> On 03/31/2018 02:18 PM, Bill Fenner wrote:
>
> On Wed, Mar 28, 2018 at 1:09 PM, Ian Bruene  wrote:
>>
>>
>> #2823 Is fixed.
>
>
> This was the one that you later mentioned on irc, and the formatting misled
> you into thinking that it was fixed but it isn't?
>
>
> Yes, looking into it now.
>
>
> [various closings]
>
> Thanks!
>   Bill
>
>
> Thanks!
>
> --
> "In the end; what separates a Man, from a Slave? Money? Power? No. A Man
> Chooses, a Slave Obeys." -- Andrew Ryan
>
> "Utopia cannot precede the Utopian. It will exist the moment we are fit to
> occupy it." -- Sophia Lamb
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Does Net-SNMP support AES192 or AES256?

[Keith Mendoza]

Simon,
Those options have to be enabled in the configure options. I suggest
building with the following configure options:
--with-transports="DTLSUDP" --with-security-modules="tsm"

There might be other configure options that you need to make it work.

Just note though that SNMPv3 RFC _does not_ specify AES192 and AES256;
they specified some older algorithms that were "latest and greatest"
at the time it was being drafted :(

Thanks,
Keith
Thanks,
Keith


On Thu, Apr 5, 2018 at 1:54 PM, Simon Chamlian  wrote:
>
>
>
> Hi,
>
> Does Net-SNMP support AES192 or AES256?
>
> According to this link
>
> http://www.net-snmp.org/wiki/index.php/Strong_Authentication_or_Encryption
>
> The short answer is Yes, starting with release 5.8 AES193 and AES256 are an
> optional configure option.
>
> So I downloaded version 5.8.pre2 and tried:
>
>
>   createUser user2  SHA "passwrd-00" AES192 "default-00"
>   rwuser   user2
>
>   createUser user3  SHA "passwrd-00" AES256 "default-00"
>   rwuser   user3
>
>
> Does not work. I get an error:
>   snmpd.conf: line 27: Error: unknown privProtocol
>   snmpd.conf: line 31: Error: unknown privProtocol
>
> Any insight will be highly appreciated.
>
> S.
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Unstable tests

[Keith Mendoza]

So again, at what point do we stop adding code to net-snmp because
ISP's are messing around as if they're doing us a favor by letting us
use their services?

Thanks,
Keith
Thanks,
Keith


On Wed, Apr 4, 2018 at 7:13 PM, Bart Van Assche <bvanass...@acm.org> wrote:
> On 04/04/18 09:30, Keith Mendoza wrote:
>>
>> I actually found no.such.address in line 79 of T070com2sec_simple.
>> That host has been hijacked by barefruit.co.uk who "generates highly
>> targeted traffic for ISPs by replacing DNS and HTTP errors with
>> relevant advertising"; which is now causing the test case to fail.
>> Attempting to talk HTTP to the IP gave the the impression that either
>> my ISP is cahoots with this company; or they're intercepting the IP
>> back to their advertisement page. On the upside, Google's and
>> cloudflare's DNS are not resolving; but, that still means point your
>> network to use those nameservers :(
>
>
> That means that your ISP is doing something dubious. Anyway, we could add a
> workaround for broken ISP DNS configurations using the same approach as for
> the domain names onea.net-snmp.org and twoa.net-snmp.org.
>
> Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: IRC chat to help our new guard get on board?

[Keith Mendoza]

So far, this is the time that may work for everyone if we do it the
week of April 8 (UTC and US time zones): 5:30 AM PDT/6:30 AM MDT/7:30
AM CDT/8:30 AM EDT/12:30 PM UTC--6:00 AM PDT/7:00 AM MDT/8:00 AM
CDT/9:00 AM EDT/1:00 PM UTC.

Eric,
How do you feel about having the meeting the week of April 16 to see
if we can get better timing and more people to come?

Thanks,
Keith
Thanks,
Keith


On Wed, Apr 4, 2018 at 10:20 AM, Ashutosh Kumar  wrote:
> Hi Eric, Keith and All,
>
> I am Ashutosh, and I work as a junior software developer. I got to know
> about net-snmp thanks to my previous project.
> I have just covered the basic source code as of now, (like snmpget.c,
> snmpset.c, snmptable.c, etc.)  but would like to get involved and contribute
> to the project to best of my abilities.
>
> I'm willing to attend and any time between 1:30 AM to 3:30 AM UTC and 12:30
> PM to 17:30 PM UTC would be fine by me, if that works for other developers.
>
> Thanks,
> Ashutosh
>
> On Wed, Apr 4, 2018 at 6:24 AM, Eric S. Raymond  wrote:
>>
>> ICEI has a #newguard channel on freenode where its "new guard" -
>> programmers who want to get involved in infrastructure work - hang
>> out.
>>
>> Some of them are interested in contributing to net-snmp. Joining Ian
>> on the bug triage would be an obvious way to on-board them, but that
>> will work better if they have more sense of the scope and direction of
>> the project and feel like they know its key people.
>>
>> We'd like to set up a time for a short IRC conference for them to get
>> to know your project's senior devs and vice-versa. Ian and Keith and I
>> will be there, of course. We can talk about what needs to be done and
>> recruit you some more help.
>>
>> We'd like to especially invite your project owner and release manager
>> and tech lead (understanding that those might be the same person) but
>> any net-snmp dev would be welcome and the more the better
>>
>> If you're willing to attend, please respond with your name, your
>> project role, and some indication of when you could be free for a
>> 45-minute IRC chat within the next ten days.
>> --
>> http://www.catb.org/~esr/;>Eric S. Raymond
>>
>> It would be thought a hard government that should tax its people one tenth
>> part.   -- Benjamin Franklin
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Net-snmp-coders mailing list
>> Net-snmp-coders@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Unstable tests

[Keith Mendoza]

Bart,


On Sun, Apr 1, 2018 at 8:26 AM, Bart Van Assche <bvanass...@acm.org> wrote:
> On 03/31/18 22:19, Keith Mendoza wrote:
>>
>> I personally feel that whoever is running the automated tests should
>> make the necessary changes to their environment to resolve any
>> hostname that is needed to run the tests.
>
>
> I don't have root access to the BSD and AIX systems that I use for testing
> Net-SNMP. So modifying /etc/resolv.conf or equivalent on these systems is
> not an option.

I'm wiling to take on testing BSD if you can give me the spec for the
you're using. Unfortunately, I don't  have access to an AIX hardware.

>
>> From a software development and testing point-of-view I feel that we
>> will eventually get caught in expanding the number of hostnames that
>> will have to be handled by all the hostname resolution utility
>> functions in snmplib/system.c. I haven't had a chance to do a complete
>> analysis of how many each of the *gethostbyname* function variants are
>> used through the net-snmp code base; so, I'm not going to speak as to
>> whether these changes is limited to netsnmp_gethostbyname_v4(), or
>> should be applied elsewhere.
>
>
> That's not correct. onea.net-snmp.org and twoa.net-snmp.org are the only two
> that need special handling. If more functions than
> netsnmp_gethostbyname_v4() would have to recognize these hostnames, we can
> refactor the host name resolution functions such that only one function
> needs to know about these special hostnames.

I actually found no.such.address in line 79 of T070com2sec_simple.
That host has been hijacked by barefruit.co.uk who "generates highly
targeted traffic for ISPs by replacing DNS and HTTP errors with
relevant advertising"; which is now causing the test case to fail.
Attempting to talk HTTP to the IP gave the the impression that either
my ISP is cahoots with this company; or they're intercepting the IP
back to their advertisement page. On the upside, Google's and
cloudflare's DNS are not resolving; but, that still means point your
network to use those nameservers :(

>
> Bart.
>
>
>

Thanks,
Keith

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: IRC chat to help our new guard get on board?

[Keith Mendoza]

Bart,
Thank you for your interest. Please let us know when you're free; we
will schedule the meeting based on what works best for the net-snmp
devs who would like to join us.

Thanks,
Keith

On Tue, Apr 3, 2018 at 7:11 PM, Bart Van Assche  wrote:
> On 04/03/18 17:54, Eric S. Raymond wrote:
>>
>> ICEI has a #newguard channel on freenode where its "new guard" -
>> programmers who want to get involved in infrastructure work - hang
>> out.
>>
>> Some of them are interested in contributing to net-snmp. Joining Ian
>> on the bug triage would be an obvious way to on-board them, but that
>> will work better if they have more sense of the scope and direction of
>> the project and feel like they know its key people.
>>
>> We'd like to set up a time for a short IRC conference for them to get
>> to know your project's senior devs and vice-versa. Ian and Keith and I
>> will be there, of course. We can talk about what needs to be done and
>> recruit you some more help.
>>
>> We'd like to especially invite your project owner and release manager
>> and tech lead (understanding that those might be the same person) but
>> any net-snmp dev would be welcome and the more the better
>>
>> If you're willing to attend, please respond with your name, your
>> project role, and some indication of when you could be free for a
>> 45-minute IRC chat within the next ten days.
>
>
> Hello Eric,
>
> I'm willing to attend but whether I will be able to attend will depend on
> when the IRC-chat will be held. I'm one of the Net-SNMP developers. Most
> work on the Windows ports (MSVC, Cygwin, MinGW) is done by me but as one can
> see in the git tree I make contributions all over the Net-SNMP tree.
>
> Bart.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Unstable tests

[Keith Mendoza]

I personally feel that whoever is running the automated tests should
make the necessary changes to their environment to resolve any
hostname that is needed to run the tests. In my case,
onea.net-snmp.org and twoa.net-snmp.org resolves to IP's in the
127.0.0.0/24 network; however no.such.address resolves to 92.242.140.2
which is an IP assigned to barefruit.co.uk. We now have a case of some
unscrupulous advertiser that "highly targeted traffic for ISPs by
replacing DNS and HTTP errors with relevant advertising" (that's from
their home page).

>From a software development and testing point-of-view I feel that we
will eventually get caught in expanding the number of hostnames that
will have to be handled by all the hostname resolution utility
functions in snmplib/system.c. I haven't had a chance to do a complete
analysis of how many each of the *gethostbyname* function variants are
used through the net-snmp code base; so, I'm not going to speak as to
whether these changes is limited to netsnmp_gethostbyname_v4(), or
should be applied elsewhere.

I understand full well the desire to make it as easy as possible for
as many users to be able to build, test, and deploy any open-source
software. However, I feel that the typical user's abilities should
also be considered. I feel that assuming that they can make the
necessary changes to their test environment to resolve a given set of
hostnames is a reasonable one.

Thanks,
Keith (pantherse)
Thanks,
Keith


On Sat, Mar 31, 2018 at 8:48 PM, Bart Van Assche  wrote:
> On 03/22/18 12:22, Eric S. Raymond wrote:
>>
>> Bart Van Assche :
>>>
>>> Hello Eric,
>>>
>>> These are the only two tests that sometimes fail on my test setup.
>>> Whether
>>> or not these tests pass depends on your DNS server. If I e.g. add
>>> "nameserver 8.8.8.8" as the first entry in /etc/resolv.conf then these
>>> tests
>>> pass on my setup. I think the reason is that the domain names used by
>>> that
>>> test resolve into 127.0.0.x and because some DNS servers filter these
>>> results.
>>>
>>> Bart.
>>
>>
>> You guys have been at this too long.  You're failing to document your
>> assumptions.
>>
>>> From 6cd949342a65ff2260253bca234bfa08f8e3b5c2 Mon Sep 17 00:00:00 2001
>>
>> From: "Eric S. Raymond" 
>> Date: Thu, 22 Mar 2018 15:20:21 -0400
>> Subject: [PATCH] INSTALL: explain workaround for comsec test failures.
>>
>> ---
>>   INSTALL | 11 +++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/INSTALL b/INSTALL
>> index aad9099..9bcd65a 100644
>> --- a/INSTALL
>> +++ b/INSTALL
>> @@ -6,6 +6,7 @@ TABLE OF CONTENTS
>>   * Net-SNMP Specific Information
>> Long (but you should read these) Instructions
>> Installing the Perl/SNMP Module
>> +  Tests
>>   * Compilers and Options
>> Compiling For Multiple Architectures
>> Installation Names
>> @@ -155,6 +156,16 @@ Net-SNMP libraries and demon applications.
>>   make test
>>   make install (as root)
>>   +Tests
>> +=
>> +
>> +The ordinary self-test sequence can be invoked with "make test". There
>> +are more comprehensive options.
>> +
>> +Spurious failures on the "comsec" tests can be due to misconfigured
>> +DNS upstream of you. A workaround is to point your DNS server at a
>> +non-broken one. Adding "nameserver 8.8.8.8" as the first entry in
>> +/etc/resolv.conf will do.
>> Compilers and Options
>>   =
>
>
> How about the patch below? It makes test T070com2sec_simple pass on my
> setup.
>
> Thanks,
>
> Bart.
>
> ---
>  snmplib/system.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/snmplib/system.c b/snmplib/system.c
> index d7f06f74087f..c9dbea344f71 100644
> --- a/snmplib/system.c
> +++ b/snmplib/system.c
> @@ -762,6 +762,19 @@ netsnmp_validator_context(void)
>  int
>  netsnmp_gethostbyname_v4(const char* name, in_addr_t *addr_out)
>  {
> +/*
> + * A hack that avoids that T070com2sec_simple fails due to the DNS
> + * client filtering out 127.0.0.x addresses.
> + */
> +if (strcmp(name, "onea.net-snmp.org") == 0) {
> +*addr_out = htonl(INADDR_LOOPBACK);
> +return 0;
> +} else if (strcmp(name, "twoa.net-snmp.org") == 0) {
> +*addr_out = htonl(INADDR_LOOPBACK + 1);
> +return 0;
> +}
> +
> +{
>  #if HAVE_GETADDRINFO
>  struct addrinfo *addrs = NULL;
>  struct addrinfo hint;
> @@ -826,6 +839,7 @@ netsnmp_gethostbyname_v4(const char* name, in_addr_t
> *addr_out)
>  #else /* HAVE_GETIPNODEBYNAME */
>  return -1;
>  #endif
> +}
>  }
>
>  int
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> 

Re: var_vacm_access() question

[Keith Mendoza]

Bill,
Thank you for taking the time to explain this to me. Seems to me like
I should review ASN.1, and MIB-II specs--at the minimum--before
proceeding any further. Where are dev-related documents usually
stored? I'd like to contribute my notes once when I'm done.

Thanks,
Keith
Thanks,
Keith


On Thu, Mar 22, 2018 at 3:14 PM, Bill Fenner <fen...@gmail.com> wrote:
> The oid represents a request from the user, in which the character string is
> encoded using the SNMP rules. It is converting this OID-encoded string into
> a char* string so that it can look it up in its internal tables.
>
>   Bill
>
>
> On Thu, Mar 22, 2018 at 6:13 PM, Keith Mendoza <panthe...@gmail.com> wrote:
>>
>> My next question is then, why exactly is it basically copying parts of
>> an oid into cp and basically truncating parts of it?
>>
>> Thanks,
>> Keith
>> Thanks,
>> Keith
>>
>>
>> On Thu, Mar 22, 2018 at 6:47 AM, Bill Fenner <fen...@gmail.com> wrote:
>> > On Wed, Mar 21, 2018 at 5:50 PM, Keith Mendoza <panthe...@gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >> I'm one of the volunteer developers with ICEI (please see email with
>> >> subject "ICEI asks what help you need" for details). I was attempting
>> >> to compile net-snmp code with -std=c99 compiler option, and the
>> >> compiler failed with "error: overflow in implicit constant conversion
>> >> [-Werror=overflow] on the following lines in
>> >> net-snmp-code/agent/mibII/vacm_vars.c: 382, 397, and 593. These 3
>> >> locations have *cp++ = 255;
>> >>
>> >> So, my question is where can I get more information on
>> >> var_vacm_access(). It appears to me it has something to do with
>> >> determining group access control for a MIB group. Specifically, what
>> >> is the rational for incrementing, then basically setting the location
>> >> pointed by "cp" to 255 given the if logic above each of the 3
>> >> locations where *cp++ = 255 is set.
>> >
>> > Keith,
>> >
>> > The blocks in question look like
>> >
>> > oid*op;
>> >
>> > char   *cp;
>> >
>> > ...
>> > cp = contextPrefix;
>> > for (i = 0; i <= len && op < name + *length; i++) {
>> > if (*op > 255) {
>> > *cp++ = 255;
>> > ++op;
>> > } else
>> > *cp++ = (char) *op++;
>> > }
>> >
>> > The underlying type of oid is int or long, so it becomes obvious that
>> > this
>> > code is copying values from op to cp while truncating values that won’t
>> > fit
>> > into a char.
>> >
>> > It’s probably not unreasonable to change the relevant types to u_char.
>> >
>> > Bill
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)

[Keith Mendoza]

Looking into using clang on Windows might be worth the effort to get
net-snmp code caught up to C99. Google Chrome now uses clang to
compile in Windows:
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html

Thanks,
Keith

-Original Message-
Subject: RE: C99 (was: Re: Fix patch for SF bug 2833)
Date: Thu, 22 Mar 2018 18:27:47 + (UTC)
From: Steve Friedl 
To: e...@thyrsus.com, 'Bill Fenner' 
CC: 'Net-SNMP Coders' 


net-snmp is expected to build on Windows, which gpsd does not; it's not
clear how much this impacts compiler choice.

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com]
Sent: Thursday, March 22, 2018 10:32 AM
To: Bill Fenner 
Cc: Net-SNMP Coders 
Subject: C99 (was: Re: Fix patch for SF bug 2833)

Bill Fenner :
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond  wrote:
>
> > On the other hand, I question whether the extra overhead is a real
> > issue in 2018.
>
>
> I have the same question, but know that I have no useful opinion here
> - my "embedded system" ships with 4 gigs minimum, but the project has
> more use cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99
constructs.

*This* is an issue about which I know something important that does not seem
to have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or portability
anywhere, I get a complaint right quick.  I've fielded dozens of these.
Maybe the weirdest one was due to actual signed chars on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from ancient
big iron in my codebase. Thought about my options, decided to move to
assuming C99 and SuSv2. I shipped a point release on this premise expecting
at least some minor pushback from some odd legacy environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one of the
time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero is
obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the
host API than snmpd does, so the test has been more stringent. GPSD has to
get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even
further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

var_vacm_access() question

[Keith Mendoza]

Hi,
I'm one of the volunteer developers with ICEI (please see email with
subject "ICEI asks what help you need" for details). I was attempting
to compile net-snmp code with -std=c99 compiler option, and the
compiler failed with "error: overflow in implicit constant conversion
[-Werror=overflow] on the following lines in
net-snmp-code/agent/mibII/vacm_vars.c: 382, 397, and 593. These 3
locations have *cp++ = 255;

So, my question is where can I get more information on
var_vacm_access(). It appears to me it has something to do with
determining group access control for a MIB group. Specifically, what
is the rational for incrementing, then basically setting the location
pointed by "cp" to 255 given the if logic above each of the 3
locations where *cp++ = 255 is set.

Thanks,
Keith

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders