[fossil-users] Fwd: Re: Fossil README symlink

2017-10-18 Thread Andy Goth 
More from Dragora about JavaScript. The part that's most interesting to me
is they're not using Github.

-- Forwarded message --
From: "Matias Fonzo" 
Date: Oct 18, 2017 13:26
Subject: Re: Fossil README symlink
To: "Andy Goth" 
Cc:

Hi Andy,

On Wed, 18 Oct 2017 09:48:44 -0500
Andy Goth  wrote:
>
> Here's the origin of the rest of the thread, if you wish to see:
>
> [..]

Thanks.

>
> I think this is a good thing.  Thank you for helping to get this ball
> rolling.  Hopefully it will bear fruit, even if it's not precisely
> what you were asking for.
>

No problem.

Two things, the report of the people is not about the login page
only.  They can't see some of the pages, cannot remember exactly those,
but i think it was about the content, and the Timeline.  I've followed
the suggestions to try to avoid Javascript, but without luck.

Probably is my bad interpretation, but we are not in Github (just in
case, to make it clear).  Currently, we have a mirror[1] in notabug.org
(which is an alternative to Github).

[1] http://notabug.org/dragora

Best regards,
Matías
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fwd: Re: Fossil README symlink

2017-10-18 Thread Ron W 
On Wed, Oct 18, 2017 at 8:00 AM, 
wrote:
>
> Date: Tue, 17 Oct 2017 20:12:25 -0500
> From: Andy Goth 
> Subject: [fossil-users] Fwd: Re: Fossil README symlink
>
>  Forwarded Message 
> Subject: Re: Fossil README symlink
> Date: Tue, 17 Oct 2017 21:49:35 -0300
> From: Matias Fonzo 
>
> Fossil is a great software and I consider it better than Git. The
> problem is the Javascript code to avoid the spam, and some people
> reported that they can not enter to the Dragora's website, which is a
> problem for me.
>

As I recall, the Javascript on the login page is to allow for anonymous
logins. If anonymous logins are not allowed, is there still any reason for
Javascript on the login page?

Of course, given that github also makes extensive use of Javascript, what
are they doing differently that doesn't cause problems for Matias?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Warren Young 
On Oct 18, 2017, at 8:51 AM, Andy Goth  wrote:
> 
> style-$hash2.css where $hash2 is a hash (or prefix thereof)
> of the contents of style.css, possibly combined with the Fossil checkin
> prefix.

If style.css is stored as a Fossil artifact, we get that for free.

If it’s stored in SQL, Fossil could use the CSS BLOB's rowid instead.

It looks like the current scheme of style.css?id=$hash could be style-$hash.css 
and do what we want.  The current 

Cache-control: max-age=28800

is a bit short for that purpose.  It could literally be millions and be fine 
under this scheme.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] enhanced-symlink branch

2017-10-18 Thread Florian Balmer 
Andy Goth:

> Does anyone know a good way to create *.lnk files from Tcl?

There's an ancient SHORTCUT.EXE command line utility:

https://ss64.com/nt/shortcut.html

It even has an -s command line option to disable link tracking.

I don't have the original. A few clones can be found in the web, but I
haven't come across an up-to-date version that allows access to modern
Shell Link properties, such as PKEY_AppUserModel_ID to control taskbar
icon grouping, and the like.

Also, the venerable Windows Scripting Host can manipulate Shell Links
by simple JS or VBS scripts, but only the basic properties:

https://ss64.com/vb/shortcut.html

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Andy Goth 

On 10/18/17 09:46, Warren Young wrote:

On Oct 18, 2017, at 8:27 AM, Warren Young  wrote:

On Oct 18, 2017, at 7:04 AM, Richard Hipp  wrote:

I'll have to add a "/fossil.js” resource


While you’re about it, I’d suggest shipping /fossil-$hash.js instead
and setting a multi-year Expires header for the file so that it only
has to be pulled once and cached “forever”.

$hash is the current Fossil checkin prefix, the same one reported by
“fossil ver”.  Thus, whenever Fossil changes, the file name changes,
so the browser will pull the fossil.js file again.


+1 to this idea.


Ditto style.css, though the ability to change the CSS via Fossil UI
complicates this.  Currently, that gets pulled on every page load,
even though it almost never changes.


+0.98 to this idea.  I'll contribute the remaining two cents by
suggesting style-$hash2.css where $hash2 is a hash (or prefix thereof)
of the contents of style.css, possibly combined with the Fossil checkin
prefix.

--
Andy Goth | 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Warren Young 
On Oct 18, 2017, at 8:27 AM, Warren Young  wrote:
> 
> On Oct 18, 2017, at 7:04 AM, Richard Hipp  wrote:
>> I'll have to add a "/fossil.js” resource

While you’re about it, I’d suggest shipping /fossil-$hash.js instead and 
setting a multi-year Expires header for the file so that it only has to be 
pulled once and cached “forever”.  

$hash is the current Fossil checkin prefix, the same one reported by “fossil 
ver”.  Thus, whenever Fossil changes, the file name changes, so the browser 
will pull the fossil.js file again.

Ditto style.css, though the ability to change the CSS via Fossil UI complicates 
this.  Currently, that gets pulled on every page load, even though it almost 
never changes.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Javier Guerra Giraldez 
On 18 October 2017 at 15:32, Stephan Beal  wrote:
> LOL. Turing and his silly Test - that's why we can't have nice things.

nitpicking: it's not about the test, but about the completeness (AKA
the halting problem)

-- 
Javier
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] enhanced-symlink branch

2017-10-18 Thread Andy Goth 

On 10/18/17 08:42, Florian Balmer wrote:

Handling Windows Shell Links (*.lnk) can be tricky:


Off-topic, but does anyone know a good way to create *.lnk files from 
Tcl?  The only way I've found is to use DDE to create start menu 
shortcuts, then move those shortcut files to wherever I need them, 
because they are in fact *.lnk files.  This has some serious drawbacks, 
but again, it's the only way I've found to make *.lnk files at all.


Because off-topic, please consider replying to me privately.

--
Andy Goth | 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Stephan Beal 
On Wed, Oct 18, 2017 at 4:27 PM, Warren Young  wrote:

> If you have any Ajax calls back to the remote fossil executable and they
> ship back

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Warren Young 
On Oct 18, 2017, at 7:04 AM, Richard Hipp  wrote:
> 
> On 10/18/17, Warren Young  wrote:
>> On Oct 18, 2017, at 3:44 AM, Warren Young  wrote:
>>> 
>>> The more web apps that ship with stringent Content-Security-Policy
>>> headers, the fewer arguments we’ll have for allowing JS on web pages.
> 
> I'd never heard of Content-Security-Policy before.  A quick scan
> suggests that I need to modify Fossil to make use of it.
> 
> Target policy:  default-src: ‘self'

Eventually, ideally, yes. 

At the moment, this might work without causing any errors:

default-src 'self’;
script-src 'self' 'unsafe-inline’;
style-src 'self' 'unsafe-inline’;

The exceptions allow all the inline style=“” attributes and

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Richard Hipp 
On 10/18/17, Lonnie Abelbeck  wrote:
>
> Doesn't HTTPS solve this problem ?
>

HTTPS solves a different problem.  See
https://content-security-policy.com/presentations/ for some
presentations that describe the problem that CSP solves.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] enhanced-symlink branch

2017-10-18 Thread Florian Balmer 
Warren Young:

> By that reckoning, I’d rank *.lnk above Cygwin symlinks in many
> regards. Why wouldn’t that work?

Handling Windows Shell Links (*.lnk) can be tricky:

There's built-in logic to resolve links to missing targets (called
"link tracking", can be disabled). That's why portability of *.lnk
files may be limited across machines, and Fossil would have to keep
the link information separately, and create *.lnk files as needed.

https://technet.microsoft.com/en-gb/magazine/2009.10.windowsconfidential.aspx

Also, there's other *.lnk file options that may affect portability:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb762540.aspx

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Lonnie Abelbeck 

On Oct 18, 2017, at 8:04 AM, Richard Hipp  wrote:

> On 10/18/17, Warren Young  wrote:
>> On Oct 18, 2017, at 3:44 AM, Warren Young  wrote:
>>> 
>>> The more web apps that ship with stringent Content-Security-Policy
>>> headers, the fewer arguments we’ll have for allowing JS on web pages.
> 
> I'd never heard of Content-Security-Policy before.  A quick scan
> suggests that I need to modify Fossil to make use of it.
> 
> Target policy:  default-src: 'self'
> 
> That means, no more in-line javascript, which will be a hassle to work
> around.  I'll have to add a "/fossil.js" resource that contains
> various scripts and insert the JSON data used to drive those scripts
> as

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Stephan Beal 
On Wed, Oct 18, 2017 at 3:04 PM, Richard Hipp  wrote:

> as

[fossil-users] Content-Security-Policy Was: Fossil README symlink

2017-10-18 Thread Richard Hipp 
On 10/18/17, Warren Young  wrote:
> On Oct 18, 2017, at 3:44 AM, Warren Young  wrote:
>>
>> The more web apps that ship with stringent Content-Security-Policy
>> headers, the fewer arguments we’ll have for allowing JS on web pages.

I'd never heard of Content-Security-Policy before.  A quick scan
suggests that I need to modify Fossil to make use of it.

Target policy:  default-src: 'self'

That means, no more in-line javascript, which will be a hassle to work
around.  I'll have to add a "/fossil.js" resource that contains
various scripts and insert the JSON data used to drive those scripts
as

Re: [fossil-users] Fossil README symlink

2017-10-18 Thread Warren Young 
On Oct 18, 2017, at 3:44 AM, Warren Young  wrote:
> 
> The more web apps that ship with stringent Content-Security-Policy headers, 
> the fewer arguments we’ll have for allowing JS on web pages.

Wow…caffeine isn’t working yet, obviously.

What I meant to say is that the more web sites and web apps that ship with 
stringent CSP headers, the fewer *good* arguments we’ll have for *disallowing* 
JS on web pages.  That is to say, with a strong CSP, many of the arguments 
against allowing JS to run by default go away.

This article explains the whys and wherefores:

   https://developers.google.com/web/fundamentals/security/csp/ 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil README symlink

2017-10-18 Thread Stephan Beal 
On Wed, Oct 18, 2017 at 11:44 AM, Warren Young  wrote:

> A great many of the old concerns about the security problems with
> Javascript have gone away through various efforts, and atop that, the vast
> majority of web sites and web apps now require JavaScript.
>

Including *cough* github *cough*. It loads about 92k of JS on its home
page, and then sends of 2 XHR requests after that.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil README symlink

2017-10-18 Thread Warren Young 
On Oct 17, 2017, at 7:12 PM, Andy Goth  wrote:
> 
> requiring JavaScript access has proven to be
> fatal for his project's usage of Fossil.

I noticed a complete lack of “me, too” in that thread.  Usually when one of the 
other VCSes does something different from Fossil, people are quick to jump on 
it as a weakness of Fossil, but here…?

I think the no-JavaScript fight is long over, and I say that as a longtime user 
of NoScript.

A great many of the old concerns about the security problems with Javascript 
have gone away through various efforts, and atop that, the vast majority of web 
sites and web apps now require JavaScript.

Furthermore, most of the sentiment about how web sites should run without JS 
applies to content-providers, not to web apps.  It is understood that web apps 
work a whole lot better if you can do a lot of the processing on the client 
side, rather than eat an HTTP round-trip every time any significant computation 
must be done.

I do have one positive contribution to this, though it’s really too early for 
me to be commenting seriously on it: Someone™ should run OWASP ZAP against 
Fossil and see what it would take to placate it:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Unlike the recent fight about compiler warnings on the SQLite mailing list, ZAP 
tends to highlight actual problems.  The more web apps that ship with stringent 
Content-Security-Policy headers, the fewer arguments we’ll have for allowing JS 
on web pages.

I suspect it would be fairly difficult to get Fossil to ship such a CSP.  I 
seem to recall that it uses a lot of inline CSS and JS, which are a problem 
from a CSP standpoint, particularly for an app like Fossil which is all about 
user-provided content.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users