My TortoiseGit showed a strange behaviour: When I tried to push or pull, the window took exactly 5 minutes to appear. The commit window did not appear any more. Reinstalling TortoiseGit did not fix the issue. I used the git Bash as a workaround for some time until I found a fix: TortoiseGit was not able to write into its temp directory because the security settings (NTFS rights) were somehow messed up. For the C:\Users\MyUser\AppData\Local\Temp\TortoiseGit, I added my user with full access rights and everything is now working again :).
Hope this helps someone to fix this faster in case someone has the same issue.
It seems currently people have a very close look at security of phpLiteAdmin. This is really good. We immediately fix any security issue we get aware of. Therefore, we yesterday released another security patch with version 220.127.116.11. The security issue fixed in this version is an XSS vulnerability. The risk of this particular issue is considered medium. All users of phpLiteAdmin < 18.104.22.168 are advised to update to the new version. Users of the development version of 1.9.4 should please update to the latest revision from svn, at least revision 317 (2013-01-14).
We are really sorry for those users who needed to update phpLiteAdmin three times in the last days. But the only way to solve security issues is to patch, just ignoring them will not help.
Thanks a lot to Urd for making us aware of this issue. If anybody thinks he found a security issue, please do as Urd did and contact us.
To update phpLiteAdmin, just download the new version, adjust the configuration and replace the phpliteadmin.php with the new one.
member of the phpLiteAdmin team
Yesterdays security release for phpLiteAdmin unfortunately did not fix the security issues described by an exploit published by “l@usch” completely. Therefore, today a new release 22.214.171.124 was published to cover the remaining issues.
All users of phpLiteAdmin < 126.96.36.199 are advised to update their installation to 188.8.131.52. The fixed security issues can only be used by users with access to phpLiteAdmin, i.e. users that know the password. As a general recommendation, you should always use a secure password an keep it secret. Never use the default password on a publicly accessible installation.
I’d like to thank l@usch for reporting the issue and his cooperation to resolve it.
To update, just download the new version, adjust the configuration and replace your old phpliteadmin.php with the new one.
Today, a security issue of phpLiteAdmin was discovered and published. The new version 184.108.40.206, which has just been released, fixes this issue. All users of phpLiteAdmin are recommended to update their installation to the current version 220.127.116.11.
The security issue can only be used by users with access to phpLiteAdmin, i.e. users that know the password, to gain more rights on the system. Therefore, the issue cannot be exploited if you use a strong password an keep it secret. For this reason, this is always recommended. Please never use the default password if phpLiteAdmin is publicly accessible over the internet.
To update phpLiteAdmin, just adjust the configuration in the new version and replace the phpliteadmin.php with the new one. Done in a minute or two.
You can download the new version here.
Screenshot of phpLiteAdmin 1.9.3
Some minutes ago, I released the new version of phpLiteAdmin, a web management GUI for SQLite databases written in PHP. You can download it from our project site.
The new version addresses and mostly fixes lots of issues. Among these, one security issue has been fixed. Therefore, I’d recommend anybody using phpLiteAdmin to update.
A lot of work has gone into this release, fixing lots of bugs to make phpLiteAdmin more robust. For example, you can now have tables or columns containing special characters. The ALTER TABLE features have been partly rewritten so they now work a lot more reliable. And lots of other issues have been fixed. Thanks to anybody who reported bugs to the bug tracker.
If you still have any problems or suggestions, please let us know on our issue tracker.
CrazyStat version 1.70 (and before) detects Firefox version 11 (and upwards) as “Firefox 1.x”.
Firefox versions were really coming up fast lately, so I did not finish version 1.71 to get all those new versions added before they come out.
To fix this issue in 1.70 (or before), simply add “Firefox/11=Firefox 11” to stat/usr/keywords/browser.txt or even better download the current browser.txt from SVN. Just replace the file and clean the cache.
Note that you can easily customize browser detection as described in FAQ.
Of course this won’t be an issue in upcoming 1.71.
After upgrading Typo3 from 4.1.6 all the way to 4.5.10, mails sent through the default Typo3 mailforms were messed up because the charset was wrong. The charset of the page was ISO-8859-1 consistently everywhere, but the Typo3 mailform expected input to be in UTF-8 and sent the mails as UTF-8 although the browser sent the data encoded in ISO-8859-1.
After lots of things I tried, the following TypoScript fixed the problem. You simply put it into the TS of the Template.
Of course you can put another charset in there if you have a similar problem with another charset.
It took me so long to find this out as the Typo3 code editor did not know the setting and it was not documented anywhere I looked at.
Maybe this helps somebody…