I noticed Fossil 2.7 came out, so I upgraded ChiselApp.com to it. Good luck !

Thanks!

I have my own self hosted repositories, but ChiselApp is the default reference I provide in workshops when people ask me about a GitHub like service for Fossil. Do you have the JSON interface of Fossil enabled there? I have it enabled in my Fossil repositories at it has come pretty handy.

The JSON interface is enabled, as well as the forum feature (however I've only tested this to a limited degree).

Also, Tcl is enabled as well !

I haven't logged into my account, but I did notice this in the footer:

Fossil version 1.34 [62dcb00e68] 2015-11-02 17:35:44 UTC

I see the same on the Chisel home page, but in my repo I see Fossil 2.7 [9aa9ba8bd2] 2018-09-22 17:40:11

Creating repositories with repository codes is failing for me on the new site. The creation page comes back with a 500 but the repositories show up in my dashboard. However, the edit and delete links there also 500. I can still access the edit and delete pages of my older repositories.

Likely the SQLite used by newer versions of Fossil cannot be understood by the system version of SQLite. I'll work on it soon !

Is this "system version of SQLite" being used as a library, a CLI program, an interactive shell, or some combination?

I ask because if you're not using it as a library, you might not need a separate version of SQLite at all: you can just use fossil sql everywhere you currently use sqlite3.

If you need a library, it should be straightforward to make a local build of the SQLite library bundled with Fossil, so they're always in synch.

I see the same problem - I have registered after the update and couldn't get anything working. I see currently 1 private repository and 2 public ones, where the 500 error comes up.

There is a workaround, however. You can init the repository locally and upload it - and everything is working just fine, including deleting the repository again.

I didn't even notice uploading a repo is a possibility until much later, when I was ready to give up.

Majka

Do you mean uploading a new repository, or somehow uploading a replacement repository? I know of the upload function but I'd like to use the specific name that I accidentally filled with a broken repo.

In any case, thanks for the insights!

This should all be fixed. I compiled a new SQLite package for my Linux distribution and then created a custom package for PHP's SQLite to use the system SQLite... I really wish SQLite had better compatibility.

Thanks much rkeene, appreciate it!

HTTPS support would be useful for the service. Can't even open https://chiselapp.com/

HTTPS support is indeed enabled.

Currently, when I visit https://chiselapp.com/, I get redirected to http://chiselapp.com.

Could this be an old redirect that's still active?

We don't need rkeene's reply on this, because we can inspect it directly. Hitting the HTTPS URL gives this response:

HTTP/1.1 302 Moved Temporarily
Date: Tue, 13 Nov 2018 09:48:46 GMT
Server: Apache/2.4.37 (Unix) OpenSSL/1.0.2p
X-Powered-By: PHP/5.6.38
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://chiselapp.com/
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

So yeah, it's sending you back to HTTP.

The login form POSTs to HTTPS, but that's bad style, because it makes the login form look insecure to anyone who isn't able to make that inspection.

For a web app like Chisel, I'd say it should redirect all HTTP to HTTPS at the front-end proxy layer, not even allowing HTTP.

Beware when doing so: there's a setting under Admin → Access, "Redirect to HTTPS on the Login page" which if enabled causes an endless redirect loop when coupled with front-end HTTPS redirection. You have to disable it if the front-end proxy (Apache in this case) is doing the redirection.

Not only this, as you browse the site it bounces you back and forth between http and https depending on what page you’re accessing - presumably based on whether there is anything sensitive (or rather user-specific) displayed. The public repositiories page, for example, is HTTP; public repos default to HTTP but accept HTTPS.

Webapps should use HTTPS everywhere, but it’s not uncommon, albeit less secure, to serve only signed-in users over HTTPS (for example I think reddit still works this way, or it did for a while). The bigger issue is having signed-in users on HTTP at all, because sending a login cookie unencrypted is about as secure as an unencrypted login page.

For split HTTP and HTTPS, the login cookie (phpsessid?) needs to have Secure set so it’s never sent unencrypted. Since fossils can push arbitrary JavaScript it should also have HTTPOnly set, to prevent session hijacking through that method.

So yeah, it's sending you back to HTTP.

Thanks for the info, Warren, but... that much I already knew. :-)

I was wondering what is causing the server to do this; but that is something Roy will have to look into.

It would appear Chiselapp was designed to only use HTTPS in very specific cases, because some pages do work with HTTPS, but the links generally use HTTP. (It’s actually the first time I’ve come across a site that explicitly redirects from HTTPS to HTTP, on a login page no less).

I agree that web apps ought to be fully HTTPS-enabled, especially in this case, seeing as any fossil repository will be sending out user-generated content.

As for the https-login setting, doesn’t Fossil see that it’s being called on an HTTPS URI? If it’s using a proxy, is there no way for the proxy to pass this information along?
On my server at least, running via CGI on Apache, Fossil appears to be aware of this, since the login page gives out a warning that the login will be sent over an unencrypted connection, and recommends going to the HTTPS page instead. It doesn’t give this warning on an HTTPS connection. But I guess that depends on the way the front-end server calls fossil; via CGI or actual proxy.

that much I already knew

I think I've found our problem, and I have a quick solution:

  $ sed -i'' -e '/^exception/d' config/secure.cnf 

A better solution is for nano/router.php to be rewritten not to look at that file at all, and to just force everything to HTTPS. (Besides which, re-parsing an INI file on each HTTP hit? Ugh.)

Even better than that is to do the redirect at the Apache config level, with the PHP code just blindly assuming HTTPS.

doesn’t Fossil see that it’s being called on an HTTPS URI?

When proxying using Apache or similar, you're usually either running Fossil on HTTP bound to localhost or using SCGI, so no, it's not using HTTPS, and you wouldn't want it to be doing so. That's why you get the infinite loop: it sees that it isn't HTTPS, so it redirects to HTTPS, and then it sees that it isn't HTTPS, so it...on and on.