I couldn't resist. As a publisher...maybe you shouldn't run ad block eh? :)
On Thu, Apr 17, 2014 at 12:09 AM, Sergey Bugaev (JIRA)
<noreply(a)reactos.org>wrote:
>
> [
> http://jira.reactos.org/browse/ONLINE-446?page=com.atlassian.jira.plugin.sy…]
>
> Sergey Bugaev resolved ONLINE-446.
> ----------------------------------
>
> Resolution: Cannot Reproduce
>
> > "Prove you are a human" game is hidden by AdBlock
> > -------------------------------------------------
> >
> > Key: ONLINE-446
> > URL: http://jira.reactos.org/browse/ONLINE-446
> > Project: ReactOS Online Service
> > Issue Type: Improvement
> > Reporter: Sergey Bugaev
> > Assignee: Aleksey Bragin
> >
> > https://www.reactos.org/user/register (use incognito mode or just log
> out to see the issue)
> > There is a game to prove you are a human.
> > However if you are using AdBlock (
> https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkb…,
> the most popular Chrome extension with more than 15 million users) the game
> is not visible, so newcomer can't register.
> > The error message is "You didn't pass the game", which is not very
> informative in that case.
> > Should be something like "You didn't pass the game, try disabling
> AdBlock to see it". The best solution would be making the game visible
> anyway.
> > Tested in Google Chrome
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-bugs
>
Dear all,
In case you don't use SSL/TLS on our infrastructure (web sites - drupal,
jira, fisheye), skip reading (and reconsider your choices about such
non-usage).
As you may (should?) have heard recently, OpenSSL has suffered a
critical security vulnerability (CVE-2014-0160), known as Heartbleed Bug
(http://heartbleed.com/). Most of our services were using an affected
release of OpenSSL, with heartbeat feature activated. Be it, mails
services, web services (Drupal, Jira).
We reacted quickly passed the public announcement, and the availability
of the fix to apply it on our infrastructure to limit the risks. Anyway,
this might have been enough (actually, the issue has been here for two
years!) to allow potentials attackers to, for instance, steal our SSL
private keys. So, we took the decision to renew all our certificates and
private keys to guarantee safe infrastructure usage.
Due to the nature of the security issue, we don't know what may have
been compromised in the infrastructure and in the user database. Hence
our drastic measures.
What does it mean for you? It means that your account information
(username + password) might have been compromised, and your account
itself could have been compromised (cookie stealth with the attack).
We highly recommend you to change your passwords and check that
everything is fine on your account. I shall remind you that password
change can take up to 6h to propagate to Fisheye & Jira.
As a side note, we enabled a while ago Perfect Forward Secrecy on our
infrastructure that should ensure that even if our private keys leaked,
your past communications (so, login on the infrastructure, for instance)
can't be deciphered. Unless your session ticket leaked as well...
We are really sorry for the caused inconvenience. I'm available by email
or on IRC to answer your questions and clear your doubts.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hi all,
With this few words I would like to share the joyous event of MMIO-based
serial port implementation
has finally worked for me.
This is the equivalent of earlycon serial port implementation in Linux with
some extension
(so now it is even better then Linux one)
Some work yet is needed to be done to transform the work into the normal
patch, but the good news is
it is working, and still doesn't require PNPmanager for work, i.e. it
starts very early in kernel and writes kernel log messages.
I use ExpressCard 34 extension board Serial RS232 port, on laptop,
but think it will work fro PC Cards too (former name PCMCIA).
==Importance: Touching the hardware==
For the more developers we need more working PC models ( Real Hardware)
Almost all modern PCs are laptops with PCIe bus (the rest are desktops)
(but few of them able to boot the ReactOS)
Modern serial ports are recommended to use /often use MMIO-based data
transfer instead of former I/O ports.
So now possibility appears to debug these new computers and force the
ReactOS to work on this important part of new PCs.
Thanks for attention
-Minas Abrahamyan
PS Curious note: for catching the debug logs I use the (small and cheap)
soap box-sized microcontroller board with LCD (ready-unit), and I call it
"ReactOS debug logger" appliance. It doesn't take space and doesn't produce
any noise
I don't really see the reason here. Whether using the secure function or
not is is a question of whether we need null-termination or not.
If we need it the secure function will do the right thing. If we do not
need null-termination the non-secure function does the right thing and
the secure function would not add any security, but simply do the wrong
thing.
MSDN says about the lfFaceName member of the LOGFONT structure "A
null-terminated string that specifies the typeface name of the font. "
So we want it to be null-terminated and adding one more character does
not add anything useful, but will result in a broken structure.
Another difference is that the non-secure function pads the destination
array with nulls, the secure function does - afaik - not. If that is the
reason, I'd prefer zeroing it out before copying the string.
Am 06.04.2014 22:20, schrieb pschweitzer(a)svn.reactos.org:
> Author: pschweitzer
> Date: Sun Apr 6 20:20:39 2014
> New Revision: 62675
>
> URL: http://svn.reactos.org/svn/reactos?rev=62675&view=rev
> Log:
> [CHARMAP]
> Use rather wcsncpy(). A bit less safe, but at least, data are copied till possible
>
> Modified:
> trunk/reactos/base/applications/charmap/lrgcell.c
> trunk/reactos/base/applications/charmap/map.c
>
> Modified: trunk/reactos/base/applications/charmap/lrgcell.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/charmap/…
> ==============================================================================
> --- trunk/reactos/base/applications/charmap/lrgcell.c [iso-8859-1] (original)
> +++ trunk/reactos/base/applications/charmap/lrgcell.c [iso-8859-1] Sun Apr 6 20:20:39 2014
> @@ -48,9 +48,9 @@
> hdc);
>
> lf.lfCharSet = DEFAULT_CHARSET;
> - wcscpy_s(lf.lfFaceName,
> - sizeof(lf.lfFaceName) / sizeof(lf.lfFaceName[0]),
> - lpFontName);
> + wcsncpy(lf.lfFaceName,
> + lpFontName,
> + sizeof(lf.lfFaceName) / sizeof(lf.lfFaceName[0]));
>
> hFont = CreateFontIndirectW(&lf);
>
>
> Modified: trunk/reactos/base/applications/charmap/map.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/charmap/…
> ==============================================================================
> --- trunk/reactos/base/applications/charmap/map.c [iso-8859-1] (original)
> +++ trunk/reactos/base/applications/charmap/map.c [iso-8859-1] Sun Apr 6 20:20:39 2014
> @@ -228,9 +228,9 @@
> ReleaseDC(infoPtr->hMapWnd, hdc);
>
> infoPtr->CurrentFont.lfCharSet = DEFAULT_CHARSET;
> - wcscpy_s(infoPtr->CurrentFont.lfFaceName,
> - sizeof(infoPtr->CurrentFont.lfFaceName) / sizeof(infoPtr->CurrentFont.lfFaceName[0]),
> - lpFontName);
> + wcsncpy(infoPtr->CurrentFont.lfFaceName,
> + lpFontName,
> + sizeof(infoPtr->CurrentFont.lfFaceName) / sizeof(infoPtr->CurrentFont.lfFaceName[0]));
>
> infoPtr->hFont = CreateFontIndirectW(&infoPtr->CurrentFont);
>
>
>
>
This will make any failure messages in the loop useless, since you
won't know which test they're about.
Just because the tests are succeeding now doesn't mean they always will.
On 2014-04-06 17:51, hbelusca(a)svn.reactos.org wrote:
> @@ -188,7 +190,6 @@
>
> for (i = 0; i < TestCount; i++)
> {
> - trace("i = %d\n", i);
> switch (TestCases[i].PrefixType)
> {
> case PrefixNone:
>
>
Nice one :-). I thought you'd commit your ReactOS 1.0 patch today!
Beware though, you're sitting BUGCODE_NDIS_DRIVER.
Regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Working on DB server atm (hence the fails). Results will be properly
submitted later on.
Ignore failed shell errors for the next hour.
Sorry about that.
On 04/01/2014 11:24 AM, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/3636
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_2
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 62598
> Blamelist:
>
> BUILD FAILED: failed shell
>
> sincerely,
> -The Buildbot
>
>
>
>
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation