OpenCPN Version 4.4 Released

[CarCode]

Since Apple tighten for each OS update the security holes more and more, it is time to fix the Mac OS X for this matter. The actual OpenCPN version 4.4.0 from opencpn.org shows these holes:

Evaluating the application “OpenCPN4.4.app”.

The application is unsigned.
Gatekeeper assessment: PASS (no usable signature).
Executable code for x86_64 has the UUID “8F43A36C-AA2D-3C4C-9BFA-893EF1C3A4D9”.


20 auxiliary executables have been found.
904 data files have executable permissions, but should not.
20 executables are unsigned.
15 executable files have no executable permissions, but should.

To get detailed informations use "RB App Checker Lite" from the Apple App Store.

Gerhard

[nohal]

Gerhard...
No doubt the documentation files should not be executable. But could you please link some resource confirming that the .dylibs should really be executable as this tool suggest? On all the platforms I have ever seen this would be what you call "security hole".

Thanks

Pavel

[fgd3]

Originally Posted by tom_BigSpeedy

Hi,

I just noted that a nice little feature got lost with the latest commits on master branch. It is still working in the official O 4.4 though ...

Doubleclick on a track to open the properties window:

At least when OpenGL is turned off, and you click on one of the recorded track points, the current position is centered on screen (still working now) and the track point is highlighted.

The highlighting of the track point is missing now ...

See the screenshot, please :


Attachment 127538

I can't tell you until when it was working with OpenGL on (it's missing there since quite a long time), but it did work with OpenGL off till a couple of days ago ...


Best,

Thomas

It doesn't work that way for me. The Properties window opens but nothing is highlighted. Not much help if you want to know anything about that point on the track.

Fabbian

[CarCode]

Originally Posted by nohal

Gerhard...
No doubt the documentation files should not be executable. But could you please link some resource confirming that the .dylibs should really be executable as this tool suggest? On all the platforms I have ever seen this would be what you call "security hole".

Thanks

Pavel

I use Xcode v8 beta for my own OpenCPN version and get this output checking the resulting bundle:

Evaluating the application “OpenCPN.app”.

The application is unsigned.
Gatekeeper assessment: PASS (no usable signature).
Executable code for x86_64 has the UUID “52953131-8810-30C5-9035-5755FA55F8B6”.


There is one embedded framework.

39 auxiliary executables have been found.
39 executables are unsigned.

Checking the OS X folders /usr/lib/ and /usr/local/lib/ with "ls -l" command all *.dylib files have the x attribut set. Hope this answers your question.

Gerhard

[nohal]

Gerhard...
No, it unfortunately does not answer my question. My question is why it is a "security hole" not to set +x on the dylibs as you say.

Pavel


Sent from my iPhone using Cruisers Sailing Forum

[rgleason]

Gilletarom thankyou for testing the PLB ais. Don't you think this should be put in tracker as AIS PLB request so it is not lost?

Originally Posted by Gilletarom

Hello Dave,

I have, on board, personal beacons type AIS MOB (Not AIS SART). I tested one of them (using the test button). I had before ticked all the boxes for the options that the alarm responds.


On the screen, we saw a small green square with a green cross. But no alarm sounded.

I have recorded the NMEA stream with VDR. But when I wanted to read, no green square is appeared on the screen.

I have three indications of improvement to offer.
- First: Increase size of ca green square and especially the size of the red square that appears in a real fall in the water of a teammate.

- Second: Improve VDR that records all data from such tests and to allow the "replay"

- We may ask, in the OpenCPN options, the alarm created by a MOB SART is displayed or not. We can not ask the alarm created by AIS MOB appears. Is it possible to change OpenCPN for this alarm is also displayed.

[CarCode]

Originally Posted by nohal

Gerhard...
No, it unfortunately does not answer my question. My question is why it is a "security hole" not to set +x on the dylibs as you say.

Pavel


Sent from my iPhone using Cruisers Sailing Forum

So there are some misunderstandings.

Gerhard

[nohal]

Gerhard...
This unfortunately also does not answer my question.
Please post some information relevant to your claims about security, not this chit chat.

Pavel


Sent from my iPhone using Cruisers Sailing Forum

[RhythmDoctor]

I tried to set up a portable install of v4.4 on a SD card last night. The user manual is a little out of date on this (missing some DLLs that are apparently needed), but I was able to overcome that. However, piano keys and chart groups were not working (even after forcing a rebuild of the database), and the window just hung without the ability to pan to different areas of the chart. The program did not crash, so I do not have a crash report to send.

Has anyone else tested v4.4 in portable mode? I've used versions prior to 4.2 in portable mode for a few years without any problem.

[Hakan]

RD..
I'm running 4.4.0 in portable mode on Win 10 just now, although not on a SD but as a second instance of O on he same PC. No problem, works as usual.
Maybe a silly question, but you remembered to use the -p switch, did you?
Håkan

[RhythmDoctor]

Originally Posted by Hakan

RD..
I'm running 4.4.0 in portable mode on Win 10 just now, although not on a SD but as a second instance of O on he same PC. No problem, works as usual.
Maybe a silly question, but you remembered to use the -p switch, did you?
Håkan

-p switch is in the batch file that I use to launch.

The problem is related to OpenGL accelerated graphics. If I turn it on, ENC files display properly, but RNC files bring it to a screeching halt. No problem with it on versions prior to 4.2.

[RhythmDoctor]

Originally Posted by RhythmDoctor

-p switch is in the batch file that I use to launch.

The problem is related to OpenGL accelerated graphics. If I turn it on, ENC files display properly, but RNC files bring it to a screeching halt. No problem with it on versions prior to 4.2.

...Also no problem noticed on the same machine running in normal (non-portable) mode.

[RhythmDoctor]

Originally Posted by RhythmDoctor

...Also no problem noticed on the same machine running in normal (non-portable) mode.

I need to correct this. There are issues with 4.4 in both portable and non-portable mode when OpenGL is activated. Those issues manifest themselves in different ways.

My time is very fragmented right now so no time for extensive testing. But here are some facts:

• I've run 4.0 in portable mode for over a year, no problems with OpenGL
• OpenGL is very important to me, because I like to have depth soundings right side up in course up mode
• I ran 4.2 on my desktop for awhile, but it was too buggy for me to trust in real-time chartplotter use on my boat, so I stuck with v4.0
• I've run 4.4 for a few weeks on my desktop with no problems, but apparently it defaulted to having OpenGL off and did not notice it. So I'm just now noticing the problem because I'm trying to use my settings for real-time chartplotter (OpenGL activated)
• Until this issue is resolved, I will have to continue using v4.0

I am aware of the numerous issues with OpenGL support under Windows. It's just a little puzzling to me that OpenGL works fine under v4.0 but breaks under v4.4. So it appears that the programming has as a role in this - it's not entirely Microsoft's fault.

[bdbcat]

RD...

Do you have a logfile you can share for the O44 GL difficulties?
Any more background info?

We have had no widespread reports of trouble on O44, but maybe most Windows users have not discovered OpenGL....

Thanks
Dave

[vriezenaar]

I'm running openCPN on a raspberry pi on Rasbian Jessie, with the official 7" touch screen. There is one thing I found out that is not working as I expected it, which is the clicking on the icons in the toolbar. Clicking everywhere else, such as the menu etc in OpenCPN is working perfectly fine. By using a mouse the toolbar works as well, but using the touch screen, sometimes I can highlight the button, but is does not let me click the button.

Hopefully somebody has an idea whether this is a bug, or whether I missed a option somewhere to enable it again. I already tried to enable or disable the touch screen option.

It did work in the 4.0.0 version. So it happened after updating.

Thank you!