• =?UTF-8?B?U8O2bmtl?= Ludwig (43/43) Jul 10 2017 After a long journey - it took over eight months - the new core
• Steven Schveighoffer (4/6) Jul 10 2017 Even this one isn't there... Should be here:
• =?UTF-8?Q?S=c3=b6nke_Ludwig?= (2/11) Jul 10 2017 Opened a ticket: https://github.com/CyberShadow/DFeed/issues/87
• =?UTF-8?Q?S=c3=b6nke_Ludwig?= (15/15) Jul 11 2017 Note: Due to recent issues with OpenSSL, the way OpenSSL/Botan get
• Jack Applegame (36/36) Jul 11 2017 Many thanks!
• Jack Applegame (23/23) Jul 11 2017 slightly reduced
• =?UTF-8?Q?S=c3=b6nke_Ludwig?= (3/30) Jul 11 2017 Thanks! I've pushed a fix for 0.8.1:
• tetyys (5/5) Jul 15 2017 very nice!
• =?UTF-8?Q?S=c3=b6nke_Ludwig?= (7/13) Jul 16 2017 If a user supplied image URL is passed to the "src" attribute unchecked,...
• =?UTF-8?Q?S=c3=b6nke_Ludwig?= (2/6) Jul 16 2017 https://github.com/rejectedsoftware/vibe.d/pull/1846

=?UTF-8?B?U8O2bmtl?= Ludwig <sludwig outerproduct.org> writes:

After a long journey - it took over eight months - the new core 
package is finally ready. Along with it, version 0.8.0 of vibe.d 
is released. This marks a major milestone in vibe.d's development.

Apart from offering support for using the new core package, 0.8.0 
now also employs  safe and nothrow where possible, making it 
possible to write fully  safe vibe.d applications. And of course, 
as always, there is also a long list of other improvements and 
bug fixes.

The core package can be considered as a complete rewrite of the 
original vibe-d:core package, retaining a mostly backwards 
compatible API from a library user's point of view. Lots of 
changes went into modernizing the code and removing inherent 
performance limits of the previous design*.

See the dedicated blog post for a basic explanation of the 
changes:
https://vibed.org/blog/posts/introducing-vibe-core

The change log for vibe.d 0.8.0 is listed here:
https://vibed.org/blog/posts/vibe-release-0.8.0

Finally, to make use of the vibe-core module, which is highly 
recommended outside of critical production systems, you'll have 
to manually enable it in the package recipe of your project:

- dub.sdl:
     dependency "vibe-d:core" version="~>0.8.0"
     subConfiguration "vibe-d:core" "vibe-core"

- dub.json:
     {
         ...
         "dependencies" : {
             ...
             "vibe-d:core": "~>0.8.0"
         },
         "subConfigurations": {
             ...
             "vibe-d:core": "vibe-core"
         }
     }

DUB packages:
https://code.dlang.org/packages/vibe-d/0.8.0
https://code.dlang.org/packages/vibe-core/1.0.0

* Note that no dedicated performance tuning has been done yet, so 
performance levels are expected to still be on a similar level.


BTW,  CyberShadow, I originally sent this using a NG client, but 
the thread never appeared on forum.dlang.org

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 7/10/17 8:11 AM, Sönke Ludwig wrote:

 BTW,  CyberShadow, I originally sent this using a NG client, but the 
 thread never appeared on forum.dlang.org

Even this one isn't there... Should be here: 
http://forum.dlang.org/post/mmfrsonxrfxwltkfvliw forum.dlang.org

-Steve

=?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:

Am 10.07.2017 um 15:24 schrieb Steven Schveighoffer:
 On 7/10/17 8:11 AM, Sönke Ludwig wrote:
 
 BTW,  CyberShadow, I originally sent this using a NG client, but the 
 thread never appeared on forum.dlang.org

 
 Even this one isn't there... Should be here: 
 http://forum.dlang.org/post/mmfrsonxrfxwltkfvliw forum.dlang.org
 
 -Steve

Opened a ticket: https://github.com/CyberShadow/DFeed/issues/87

=?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:

Note: Due to recent issues with OpenSSL, the way OpenSSL/Botan get 
selected as the TLS provider has changed. If you are using Botan, you'll 
have to explicitly select the "botan" configuration of the new 
"vibe-d:tls" package:

	dependency "vibe-d:tls" version="~>0.8.0"
	subConfiguration "vibe-d:tls" "botan"

or for dub.json:

	"dependencies": {
		...
		"vibe-d:tls": "~>0.8.0"
	},
	"subConfigurations": {
		...
		"vibe-d:tls": "botan"
	}

Jack Applegame <japplegame gmail.com> writes:

Many thanks!

https requests with manual memory management leads to assertion.

DMD64 D Compiler v2.074.1
DUB version 1.3.0
Linux x86_64

Test case:

/+ dub.json:
	{
		"name": "test",
		"versions": ["VibeManualMemoryManagement"],
		"dependencies": {
			"vibe-d": "~>0.8.0"
		}
	}
+/

module main;

import std.conv;
import std.stdio;
import vibe.core.core;
import vibe.http.client;

void main() {
	runTask({
		HTTPStatus status;
		requestHTTP("https://steamcommunity.com", (scope request) {}, 
(scope response) {
			status = response.statusCode.to!HTTPStatus;
			response.dropBody();
		});
		writefln("status: %s", status);
		exitEventLoop();
	});
	runApplication();
}

Result:

CoreTaskFiber was terminated unexpectedly: Assertion failure
Program exited with code 255

Jack Applegame <japplegame gmail.com> writes:

slightly reduced

/+ dub.json:
	{
		"name": "test",
		"versions": ["VibeManualMemoryManagement"],
		"dependencies": {
			"vibe-d": "~>0.8.0"
		}
	}
+/

module main;

import std.conv;
import std.stdio;
import vibe.http.client;

void main() {
	HTTPStatus status;
	requestHTTP("https://steamcommunity.com", (scope request) {}, 
(scope response) {
		status = response.statusCode.to!HTTPStatus;
		response.dropBody();
	});
	writefln("status: %s", status);
}

=?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:

Am 11.07.2017 um 15:13 schrieb Jack Applegame:
 slightly reduced
 
 /+ dub.json:
      {
          "name": "test",
          "versions": ["VibeManualMemoryManagement"],
          "dependencies": {
              "vibe-d": "~>0.8.0"
          }
      }
 +/
 
 module main;
 
 import std.conv;
 import std.stdio;
 import vibe.http.client;
 
 void main() {
      HTTPStatus status;
      requestHTTP("https://steamcommunity.com", (scope request) {}, 
 (scope response) {
          status = response.statusCode.to!HTTPStatus;
          response.dropBody();
      });
      writefln("status: %s", status);
 }

Thanks! I've pushed a fix for 0.8.1: 
https://github.com/rejectedsoftware/vibe.d/commit/c0a5050088d41b726984e3beb71b9a976aaf2ba8

tetyys <tetyys tetyys.com> writes:

very nice!

one question about the </ encoding: 
https://github.com/rejectedsoftware/vibe.d/commit/e4a600f911218c49f9984734b8ba36f193e99c17

wouldn't this 
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Image_XSS_using_the_
avaScript_directive pass normally?

=?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:

Am 15.07.2017 um 23:54 schrieb tetyys:
 very nice!

 one question about the </ encoding:
 https://github.com/rejectedsoftware/vibe.d/commit/e4a600f911218c49f9984734b8ba36f193e99c17


 wouldn't this
 https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Image_XSS_using_the_JavaScript_directive
 pass normally?

If a user supplied image URL is passed to the "src" attribute unchecked, 
then yes. But this would work regardless of the JSON escape rules and 
really needs to be prevented by the application code.

However, I just noticed that this is still possible to exploit in the 
Markdown processor. User defined HTML is filtered, but link targets are 
passed to the rendered HTML as-is (just HTML encoded).

=?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:

Am 16.07.2017 um 11:17 schrieb Sönke Ludwig:
 (...)

 However, I just noticed that this is still possible to exploit in the
 Markdown processor. User defined HTML is filtered, but link targets are
 passed to the rendered HTML as-is (just HTML encoded).

https://github.com/rejectedsoftware/vibe.d/pull/1846