SSL3 and TLS in NetSurf3.8

New to Netsurf using version 3.8

At Qualys dot com I checked the Client Side. It states that there is SSL3, TLS1.0, and TLS1.1 encryption available/enabled.

Is netsurf packaging these in the browser, or is it tapping my version of OpenSSL (v. 1.0.2p)

MHO is that these 3 encryption suites be removed as a security request.
What should be included is TLS1.2 (forward secrecy) and option for TLS1.3
perhaps NS3.9 can accomplish this.

Thanks for a very fast and basic browser, I even found a YouTube download site that works with NS3.8.

Regards
Paul S.

Re: [gccsdk] Updated SDL recipes

On Tue, 28 May 2019, alan buckley wrote:

> On 27/05/2019 22:12, Jeffrey Lee wrote:
>
>> FYI I'm currently working on a couple of SDL patches of my own (adding
>> support for red/blue swapped screen modes, and a mouse handling fix)
>> which I'll hopefully get submitted to the SDL team sometime in the
>> next few days.
> Will the red/blue swapping fix 16 bit modes as well?

The lack of support for them (64K colour modes), or is there an actual bug
on some machines/OS versions which causes corrupt rendering or similar?

So far I've got red/blue swapped and 64K colour full screen modes working,
but there's more to do in terms of detecting support & windowed output.

Cheers,

- Jeffrey

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Updated SDL recipes

On 27/05/2019 22:12, Jeffrey Lee wrote:

> FYI I'm currently working on a couple of SDL patches of my own (adding
> support for red/blue swapped screen modes, and a mouse handling fix)
> which I'll hopefully get submitted to the SDL team sometime in the
> next few days.
Will the red/blue swapping fix 16 bit modes as well?
>
> Since the SDL team appear to be a bit slow in accepting our patches,
> I'm thinking that we should add all the of the outstanding ones to the
> autobuilder recipe. I can easily do that once I've tidied/finished my
> current patches.
I agree with this. We can take them out again once upstream catches up.
> (I'm also half in the mind that we should set up our own fork of the
> SDL repository on bitbucket or similar, but that would be a bit of a
> waste if we only make a couple more changes before suddenly stopping
> and leaving the code untouched for another few years)
>
I don't think we need this as we only ever seem to get a few flurries of
activity now and again.

> Cheers,
>
> - Jeffrey
Regards,
Alan
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Updated SDL recipes

FYI I'm currently working on a couple of SDL patches of my own (adding
support for red/blue swapped screen modes, and a mouse handling fix) which
I'll hopefully get submitted to the SDL team sometime in the next few
days.

Since the SDL team appear to be a bit slow in accepting our patches, I'm
thinking that we should add all the of the outstanding ones to the
autobuilder recipe. I can easily do that once I've tidied/finished my
current patches.

(I'm also half in the mind that we should set up our own fork of the SDL
repository on bitbucket or similar, but that would be a bit of a waste if
we only make a couple more changes before suddenly stopping and leaving
the code untouched for another few years)

Cheers,

- Jeffrey


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] SimpleGit

For anyone keeping track of this thread, I've just submitted an updated
recipe that improves file handling (",xxx" suffixes are now used where
appropriate, and image files are treated as directories to allow them to
be stored in git), and fixes a few bugs/limitations in simplegit itself.

Using this new version it's now possible to correctly checkout entire
products from ROOL's gitlab server (https://gitlab.riscosopen.org/) -
e.g.:

set UnixEnv$sgit$sfix ""
sgit clone https://gitlab.riscosopen.org/Products/Disc.git Disc
dir Disc
sgit submodule init
sgit submodule update

(However note that "sgit status" will report a few differences due to some
files having asymmetric filename translation, because of redundant ",xxx"
suffixes)

I've uploaded a build of the package to my site if people want to try it
out:

http://www.phlamethrower.co.uk/misc2/simplegit-libgit2_639-4.zip

If there aren't any major issues discovered over the next few days, it
would be good to have the package in riscos.info updated, as the ability
to store filetypes using ,xxx suffixes is a big step forward for using git
for RISC OS projects (I would have enabled it earlier if I'd realised that
UnixLib had support for it built-in!)

Cheers,

- Jeffrey


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[Rpcemu] Patch to implement power-off via Portable_CommandBMU

diff -r 65e3e8e126e5 src/arm_common.c
--- a/src/arm_common.c Wed Oct 24 17:24:45 2018 +0100
+++ b/src/arm_common.c Mon May 20 20:34:55 2019 +0100
@@ -40,6 +40,7 @@
#define SWI_OS_CallASWI 0x6f
#define SWI_OS_CallASWIR12 0x71

+#define SWI_Portable_CommandBMU 0x42fc4
#define SWI_Portable_ReadFeatures 0x42fc5
#define SWI_Portable_Idle 0x42fc6

@@ -362,6 +363,12 @@
swinum = arm.reg[12] & 0xdffff;
}

+ /* Intercept Portable_CommandBMU to turn off */
+ if (swinum == SWI_Portable_CommandBMU) {
+ if (arm.reg[0] == 1) /* Remove power */
+ exit(0); // FIXME
+ }
+
/* Intercept RISC OS Portable SWIs to enable RPCEmu to sleep when
RISC OS is idle */
if (config.cpu_idle) {

Following Peter Howkins's suggestion, here attached is part one of support for powering off from inside the emulator: an implementation of Portable_CommandBMU with R0=1 (= remove power).

I couldn't work out how to exit the emulator cleanly. As far as I can see that is only currently done from the front end. I tried setting quited = 1, but the emulator freezes and then crashes a little while later.

For testing purposes therefore I simply call exit(0); if someone could let me know what I should be doing, I'd be most grateful!

--

https://rrt.sc3d.org

Re: Something went wrong with the layout engine between 4630 and 4631

On Tue, 14 May 2019 at 21:18, David Higton <dave@davehigton.me.uk> wrote:

Hi guys,

Try http://www.bbc.co.uk/news/ with versions 4630 and 4631.  Notice a
big difference?  There certainly is with the RISC OS version, and I
somehow expect it to be platform-independent.

We now handle media queries, so, because your window is wide enough,

you're getting a desktop rendering of the site now, rather than the mobile

version.

Unfortunately the page does complicated stuff with JavaScript for no

apparent reason.  Line 502 of the page source has a

<script type="text/css" id="nw-c-navigation-enhanced-css">

...

</script>

section which actually contains CSS, rather than a script.

This CSS is needed to make the page get laid out correctly.

At line 504, there's an actual JavaScript script that extracts

the aforementioned script tag's CSS content and reinserts it

into the DOM as a style element.

NetSurf doesn't handle enough JavaScript to do all these

shenanigans yet.

Cheers,

Michael